g off a git repository and had uncommitted
modifications.
[1] https://ftp.gnu.org/gnu/artanis/
2025-01-28 Bruno Haible
git-version-gen: Change suffix.
* doc/package-version.texi (Propagating the package version): Drop the
git-version-gen postprocessing line,
Bruno Haible via Gnulib discussion list writes:
> `who --version` in Debian reports "who (GNU coreutils) 9.1". Should it report
> "9.1-dirty" instead of "9.1"? I don't think the Debian developers would find
> it socially acceptable to call most of their packages "dirty". And likewise
> for other
On 1/25/25 17:13, Bruno Haible via Gnulib discussion list wrote:
But from the perspective of the developer, there's a difference: Why
force a shaming term on a developer that makes adaptations?
I don't see it like that. It's not a statement about the code but about the
state
in the version co
uot;-dirty" comes from git, yes. But git does establish naming
conventions for tarballs; that's Gnulib, through 'git-version-gen', which
does that. Therefore my proposal to change git-version-gen, to add a suffix
"-modified" instead of "-dirty".
Bruno
On 1/25/25 13:57, Bruno Haible via Gnulib discussion list wrote:
>1) Most distributions do that. For example, coreutils in Debian has 3
patches
> [1].
>
>2) Making modifications is the essence of Free Software.
> [...]
> [1] https://sources.debian.org/patches/coreutils/9.1-1/
Of co
Bernhard Voelker wrote:
> Shipping a tarball with local changes which are not committed and pushed
> is ... yes, dirty work.
No, it isn't.
1) Most distributions do that. For example, coreutils in Debian has 3 patches
[1].
2) Making modifications is the essence of Free Software.
`who --
On 1/22/25 22:22, Bruno Haible via Gnulib discussion list wrote:
> [...] to call locally modified source code
> "dirty"?!
IMO "dirty" is not a wrong word here.
With regards to software deliveries, the tarball shall be made from an
officially
committed (and pushed, for what it's worth) version.
Simon Josefsson wrote:
> I had the same thoughts as you on the '*-dirty' keyword.
Thanks for mentioning it.
> However there is a subtlety: modifying a git-owned files lead to version
> changes, which after "make dist" in most projects leads to many files
> being different compared to upstream ver
he's
> the only one who is able to produce correct code, and all other people's
> modifications must be something to warn against, hence the attribute
> "dirty". (Or maybe, in the early history of git, people were looking
> for an antonym of "clean", and pi
nd all other people's
modifications must be something to warn against, hence the attribute
"dirty". (Or maybe, in the early history of git, people were looking
for an antonym of "clean", and picked the first they found?)
In any case, I propose to change git-version-gen to replace
Bruno Haible writes:
> Simon Josefsson wrote:
>> I pushed the attached patch to make
>> the usage of 'dist-hook' a bit more consistent across gnulib.
>
>> # tarball-version
>
> Isn't there a colon missing in this line?
Yes, fixed now! Thank you.
/Simon
signature.asc
Description: PGP signatur
Simon Josefsson wrote:
> I pushed the attached patch to make
> the usage of 'dist-hook' a bit more consistent across gnulib.
> # tarball-version
Isn't there a colon missing in this line?
The git-version-gen thread reminded me that having include'able snippets
of these statements is increasingly useful... I get tired of manually
syncing the Makefile.am snippets from gnulib manual on every update in
gnulib.
What do you think of a etc/make/git-version-gen.mk include snippet?
ed. Thanks for these fixes! I pushed the attached patch to make
the usage of 'dist-hook' a bit more consistent across gnulib.
/Simon
From bafecc478e9a351fd0f98846110a34d4bde6944a Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Tue, 14 Jan 2025 07:25:24 +0100
Subject: [PATCH] git-ve
Basil L. Contovounesios wrote:
> Should 'make dist' also fail when $(srcdir)/.git does not exist
Definitely not. It would prevent "make dist" from succeeding when
run from an unpacked tarball.
Bruno
Bruno Haible [2025-01-10 12:58 +0100] wrote:
> Basil L. Contovounesios wrote:
>> Does this imply that writing to a temporary file first is never needed
>> under distdir?
>
> No. It's never needed under $(distdir) *if* the Makefile rule fails when the
> command fails.
[...]
> What is desired, is th
Basil L. Contovounesios wrote:
> >> dist-hook:
> >> echo '$(VERSION)' > $(distdir)/.tarball-version
> >>
> >> whereas the other writes the target directly.
> >
> > Here it does so because the file is inside a temporary directory. If
> > the "make dist" rule fails, the user has to remove
Bruno Haible [2024-07-26 16:27 +0200] wrote:
> Basil L. Contovounesios wrote:
>> The commentary in build-aux/git-version-gen illustrates how the files
>> .version and .tarball-version could be generated:
>>
>> $(top_srcdir)/.version:
>> echo '
Thanks -- I agree avoiding 'grep' is nice, I pushed this change inspired
by your approach.
/Simon
From 83c5387249b5bbfd32d01a51af14ac53bac1bc36 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sat, 28 Dec 2024 21:19:18 +0100
Subject: [PATCH] git-version-gen: avoid use of grep, su
On Sat, Dec 28, 2024 at 11:26 AM Simon Josefsson wrote:
>
> Jim Meyering writes:
>
> > On Sat, Dec 28, 2024 at 10:01 AM Simon Josefsson
> > wrote:
> >> Jim Meyering writes:
> >>
> >> >> if test "x$v" = xUNKNOWN \
> >> >> && test -f ${tarball_version_file}-git \
> >> >> && head
sn't really matter, but it helps to have things
>> consistent.
>
> Yes, I like that part.
I pushed the attached patch to restore behaviour a bit while we discuss
use of awk instead.
/Simon
From 55073ac71ccdcb98c8941bbfac53a71848653188 Mon Sep 17 00:00:00 2001
From: Simon Jose
On Sat, Dec 28, 2024 at 10:01 AM Simon Josefsson wrote:
> Jim Meyering writes:
>
> >> if test "x$v" = xUNKNOWN \
> >> && test -f ${tarball_version_file}-git \
> >> && head -1 ${tarball_version_file}-git \
> >> | grep -v '^$Format' > /dev/null 2>&1; then
> >> v=$(he
Simon Josefsson via Gnulib discussion list writes:
> --- a/top/maint.mk
> +++ b/top/maint.mk
Please disregard that part, it is an unrelated the change for a
completely different problem and I'm still experimenting with that patch
to see if it is the right one...
/Simon
signature.asc
Descripti
ocessing as a version number taken from the git
command. This doesn't really matter, but it helps to have things
consistent.
How about this patch? Not pushed since it is untested.
/Simon
From 48c51c7c41c8776136c74e02b8d5b94e569839ce Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: S
Oops. Thank you.
Hmm... it shouldn't be hard to make vc-dwim do the right thing by
default for projects like gnulib that VC their ChangeLog file.
On Sat, Dec 28, 2024 at 9:46 AM Bruno Haible wrote:
>
> Jim Meyering wrote:
> > I've fixed that and cleaned up via this just-pushed change:
>
> I've a
Jim Meyering wrote:
> I've fixed that and cleaned up via this just-pushed change:
I've added the mandatory ChangeLog entry for your change.
Bruno
On Fri, Dec 27, 2024 at 3:35 AM Simon Josefsson wrote:
> Hi Jim, all,
Hi Simon,
> If I run git-version-gen in a snapshot of a git repository it will
> return UNKNOWN because it cannot find out the version.
>
> Git has a .gitattribute mechanism to mark some files as 'export-
Bruno Haible via Gnulib discussion list writes:
> Hi Simon,
>
> Would you mind adding a ChangeLog entry for this commit?
Sorry about that, fixed now!
/Simon
signature.asc
Description: PGP signature
Hi Simon,
Would you mind adding a ChangeLog entry for this commit?
Bruno
Hi Jim, all,
If I run git-version-gen in a snapshot of a git repository it will
return UNKNOWN because it cannot find out the version.
Git has a .gitattribute mechanism to mark some files as 'export-subst'
which makes git-archive substitute some strings in the file, when it is
e
Bruno Haible [2024-07-26 16:27 +0200] wrote:
> Basil L. Contovounesios wrote:
>
>> $(top_srcdir)/.version:
>> echo '$(VERSION)' > $@-t
>> mv $@-t $@
>> ...
>> I'm curious why one recipe writes a temporary file first
> The real reason is that if the disk is full, the rule would l
Basil L. Contovounesios wrote:
> The commentary in build-aux/git-version-gen illustrates how the files
> .version and .tarball-version could be generated:
>
> $(top_srcdir)/.version:
> echo '$(VERSION)' > $@-t
> mv $@-t $@
> ...
> I'm
The commentary in build-aux/git-version-gen illustrates how the files
.version and .tarball-version could be generated:
$(top_srcdir)/.version:
echo '$(VERSION)' > $@-t
mv $@-t $@
dist-hook:
echo '$(VERSION)' > $(distdir)/.tarball-version
pected in the debug output, it doesn't
print the help string three times, it is merely shown in debug output.
Redirect debug output with 2>/dev/null and you will only see what the
script prints. Running 'build-aux/get-version-gen' works fine as
expected.
/Simon
> + scriptversion=2
This is invalid as I did add "set -x" to the script.
"sh -x build-aux/get-version-gen" outputs:
+ scriptversion=2022-07-09.08
+ me=build-aux/git-version-gen
+ expr 2022-07-09.08 : \([^-]*\)
+ year=2022
+ version=git-version-gen 2022-07-09.08
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or la
cd gnulib-git
./build-aux/git-version-gen# $usage printed
./build-aux/git-version-gen foobar# `0.1.5512-15498`
I'm not sure if this is by design (for backward compatibility?) or a bug.
Regards,
-vc
on
Date: Sat, 9 Jul 2022 10:27:15 +0200
Subject: [PATCH] git-version-gen: Doc fix.
Reported by Reuben Thomas in
<https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00012.html>.
* build-aux/git-version-gen (usage): Replace incorrect text with
bug report instructions.
---
ChangeL
On 6/19/22, G. Branden Robinson wrote:
> I think that if GNU doesn't have the infrastructure or personnel to
> support these, then, yes, the Savannah administrators should fork (or
> just patch) cgit to the extent necessary to suppress the exposure of
> these snapshot download links. I had no ide
G. Branden Robinson wrote:
> I've
> become uncertain about whether groff's build is doing to the right thing
> with respect to the '.version' file that it creates in Makefile.am (by
> running git-version-gen).
GNU gettext's Makefile.am happens to have the same
Hi Bruno,
At 2022-06-19T16:43:51+0200, Bruno Haible wrote:
> Hi Branden,
>
> Have things worked out for you by now? Is the .tarball-version
> workflow clear? Should we document it better in the git-version-gen
> script?
Thanks for following up. I haven't had time to dig int
Hi Branden,
Have things worked out for you by now? Is the .tarball-version workflow
clear? Should we document it better in the git-version-gen script?
Bruno
===
I wrote:
> > > By the way, if submodules are not what
one, for gnulib) was taken before I joined groff
> development.
OK, let's stick to that, then. Submodules.
> configure.ac says this.
>
> AC_INIT([GNU roff],
> m4_esyscmd([build-aux/git-version-gen --fallback 1.23.0.rc1 \
> --prefix "" .tarball-ve
uot; is being run in the first
place. It seems to simply be checking whether the git command is
installed (aren't there are more idiomatic ways to do that, like
"command -v", if I remember my POSIX correctly?). Should the exit
status of "git describe" be tested inste
Hi Branden,
> -elif test "x$fallback" = x || git --version >/dev/null 2>&1; then
> +elif test "x$fallback" = x && ! git --version >/dev/null 2>&1; then
> v=UNKNOWN
> else
> v=$fallback
I don't think that's a bug. The --fallback option is documented like this:
--fallback VERSION
erefore do the following.
$ hash=c8b8f3bbcde37a53cd226f4c9cebd0dde6aca37f
$ wget -O gnulib.tar.gz https://git.savannah.gnu.org/cgit/gnulib.git/\
snapshot/gnulib-$hash.tar.gz
$ tar xf gnulib.tar.gz
Before we can proceed, we need to patch a bug in gnulib's
"git-version-gen" script.
--- build-aux/git-version-g
Just noticed that it says: "Running without arguments will suffice in most
cases." However, there is a mandatory argument!
--
https://rrt.sc3d.org
scriptversion in git-version-gen should be kept up-to-date because
this script is used by projects that update it from gnulib
when its scriptversion changes.
* build-aux/git-version-gen (scriptversion): Update.
Fixes: 8f41f1918 ("git-version-gen: Allow 'snapshot' as .tarball-ve
Hello Assaf,
> >> I wonder how users of these tarballs would be able to identify
> >> snapshots if there is no version information.
> >
> > I find that for CI tarballs a
> > stable URL is the more important feature.
> >
>
> Somewhat related:
>
> If you're posting the tarballs to ftp.gnu.org or
Hello Bruno,
On 2019-10-13 3:18 p.m., Bruno Haible wrote:
Dmitry V. Levin wrote:
I need a non-numeric version for continuous publishing of gettext snapshot
tarballs, and I want the tarballs to be called gettext-snapshot.tar.gz,
I wonder how users of these tarballs would be able to identify
sn
Dmitry V. Levin wrote:
> > I need a non-numeric version for continuous publishing of gettext snapshot
> > tarballs, and I want the tarballs to be called gettext-snapshot.tar.gz,
>
> I wonder how users of these tarballs would be able to identify
> snapshots if there is no version information.
They
Hi,
On Sun, Oct 13, 2019 at 06:30:47PM +0200, Bruno Haible wrote:
> Hi,
>
> git-version-gen currently rejects some forms of .tarball-version:
>
> $ cat > .tarball-version
> 20191011
> $ build-aux/git-version-gen .tarball-version; echo
> 20191011
> $ cat > .tar
Hi,
git-version-gen currently rejects some forms of .tarball-version:
$ cat > .tarball-version
20191011
$ build-aux/git-version-gen .tarball-version; echo
20191011
$ cat > .tarball-version
snapshot
$ build-aux/git-version-gen .tarball-version; echo
build-aux/git-version-gen: WARNING: .t
jects (like git describe) will ignore lightweight tags
by default."
I've changed the my gettext tag from a lightweight tag to an annotated tag,
and "git describe" now behaves as expected.
=> No need to change the git-version-gen script.
Bruno
[1] https://git-scm.com/docs/git-tag
Hi,
On Sat, May 11, 2019 at 12:31:16AM +0200, Bruno Haible wrote:
> Hi,
>
> I'm using git-version-gen in GNU gettext. For the 0.20 release, I
> created an empty commit, like this:
>
> CURRENT_VERSION=0.20
> git commit --allow-empty -m "Release $C
Thanks, this looks good to me.
Hi,
I'm using git-version-gen in GNU gettext. For the 0.20 release, I
created an empty commit, like this:
CURRENT_VERSION=0.20
git commit --allow-empty -m "Release $CURRENT_VERSION"
git tag v$CURRENT_VERSION
Now, git-version-gen ignores this release commit:
$ git de
* build-aux/git-version-gen, build-aux/move-if-change (version):
--version output copyright year is now taken from script year,
so that it no longer needs to be updated by hand.
---
ChangeLog | 7 +++
build-aux/git-version-gen | 3 ++-
build-aux/move-if-change | 3 ++-
3
Paul Eggert writes:
> On 11/20/2017 11:44 PM, Bernhard Voelker wrote:
>> So my question: aren't 3-level version strings allowed by the gnits check
>> in combination with gnulib's git-version-gen script? Do we have to
>> change
>> the strictness from gnits
On 11/20/2017 11:44 PM, Bernhard Voelker wrote:
So my question: aren't 3-level version strings allowed by the gnits check
in combination with gnulib's git-version-gen script? Do we have to
change
the strictness from gnits to gnu?
I would think so, unless someone takes the time
At GNU findutils, we're trying to use gnulib's git-version-gen [1]
to derive the version string from the current git commit.
Until now, we've been using a 3-level versioning scheme X.Y.Z, e.g. the
latest tag was 'v4.6.0'. Now for any non-release commit version
befo
Paul Eggert writes:
> Markus Armbruster wrote:
>> Should we replace /-([^-]+)-g([^-]*)$/ by /.\1-\2/? Extended regexp
>> for clarity. Tighter matching would be possible, say
>> /-([0-9]+)-g[0-9a-f]{4,}$/.
>
> Sounds good, I installed the attached.
Works for me, thanks!
rom: Paul Eggert
Date: Sun, 6 Aug 2017 23:24:10 -0700
Subject: [PATCH] git-version-gen: another fix for tags with "-"
* build-aux/git-version-gen: Improve fix for tags containing "-".
Suggested by Markus Armbruster in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00
nge the tag name instead of the "-" seperating it from the number
of commits.
After the next commit, we'll get "0.2.rc1-2-cbc700". Will those two
version-compare correctly?
Example:
$ git-tag -fm test v0.2-rc1
Updated tag 'v0.2-rc1' (was 1657134)
Markus Armbruster wrote:
there's an additional problem my patch fails to address:
# Change the first '-' to a '.', so version-comparing tools work properly.
# Remove the "g" in git describe's output string, to save a byte.
v=`echo "$v" | sed 's/-/./;s/\(.*\)-g/\1-/'`;
Messes with
Paul Eggert writes:
> Thanks for reporting the problem. Unfortunately that patch didn't work
> for me, since Git sometimes outputs more than 4 hex digits after the
> "g", if needed to avoid ambiguity. Please try the attached further
> patch, which I installed.
You're right. Your incremental pat
On Sun, Aug 6, 2017 at 9:22 AM, Paul Eggert wrote:
> Thanks for reporting the problem. Unfortunately that patch didn't work for
> me, since Git sometimes outputs more than 4 hex digits after the "g", if
> needed to avoid ambiguity. Please try the attached further patch, which I
> installed.
Thank
on Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 6 Aug 2017 09:21:05 -0700
Subject: [PATCH] git-version-gen: port better to older Git
Work even if the hash contains more than 4 digits.
---
build-aux/git-version-gen | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
t;v0.1-1494-g124b9", they print "v0.1-1494-g124b9". git-version-gen
> recognizes both patterns, and normalizes the old format to the new
> one.
>
> Unfortunately, this normalization code gets confused when the tag
> contains '-'. Reproducer:
>
>
Really old versions of git-describe (before v1.5.0, Feb 2007) don't
have the number of commits in their long format output, i.e. where
modern 'git describe --abbrev=4 --match="v*"' prints
"v0.1-1494-g124b9", they print "v0.1-1494-g124b9". git-version
ad -1 configure.ac
> AC_INIT([logrotate],[m4_esyscmd([build-aux/git-version-gen --prefix ''
> .tarball-version])],
Too much quoting. This is one case where you WANT to expand the
m4_esyscmd early, as in:
AC_INIT([logrotate],
m4_esyscmd([build-aux/git-version-gen --prefix ''
not
make empty string and AC_INIT to play together without the macro starting
to throw warnings. Here is how that turns out:
$ head -1 configure.ac
AC_INIT([logrotate],[m4_esyscmd([build-aux/git-version-gen --prefix ''
.tarball-version])],
$ ./autogen.sh
configure.ac:1: warning: AC_INIT:
Hi,
Sami Kerola wrote:
> There are projects that try use this script, but do not have convention to
> use 'v' in front of tags. Earlier one had to change script default not to
> include 'v'. After this change the --prefix option can be used as last
> argument without options
In most cases, long
same.
---
build-aux/git-version-gen | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 079849d5e..f493d8157 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -101,7 +101,7 @@ while test $# -gt
t an argument operand. However, the shell script should not be relying
> on
> undefined behavior to report the error. I installed the attached patch, which
> should fix that.
Thank you. I spotted the error while testing Gnuastro build script,
indeed git-version-gen was called in this w
avior to report the error. I installed the attached patch, which
should fix that.
From dd65129dbb0c5c40ee64d189bcee5dd0765edc7a Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 8 May 2016 11:38:22 -0700
Subject: [PATCH] git-version-gen: avoid undefined shift
MIME-Version: 1.0
Content-Type:
Hi Paul,
2016-05-08 20:21 GMT+02:00 Paul Eggert :
> Mosè Giordano wrote:
>> the attached patch makes git-version-gen compatible with dash shell,
>> whose shift built-in aborts when there are no more arguments.
>
> Can you explain why that patch is needed? The 'shif
Mosè Giordano wrote:
> the attached patch makes git-version-gen compatible with dash shell,
> whose shift built-in aborts when there are no more arguments.
Can you explain why that patch is needed? The 'shift' is inside a 'while test $#
-gt 0' loop, so I don't
Hi all,
the attached patch makes git-version-gen compatible with dash shell,
whose shift built-in aborts when there are no more arguments.
Bye,
Mosè
From 0733fa62be455930e549bdee9862f075c352db3c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mos=C3=A8=20Giordano?=
Date: Sun, 8 May 2016 13:39:40 +0200
Hello there,
I would like to see the the following description of
a use-case included as a comment in git-version-gen.
Had this recipe been followed by GNU Inetutils,
then the reversal of my previous patch to git-version-gen
would never have been justified. For good or bad!
That lesson leads me
due
to a very sneeky/cunning use of "UNKNOWN":
### top/GNUMakefile: line 58 -- 61
ifneq ($(_curr-ver),$(VERSION))
ifeq ($(_curr-ver),UNKNOWN)
$(info WARNING: unable to verify ...)
else
My solution tried to resolve "UNKNOWN" into something better, but
p/GNUMakefile'.
> There is no problem with a shallow clone, but a corner
> case exists with annotated tags.
>
> The problem boils down to an issue of tag prefixes,
> namely as soon as it is not the default "v", presumed
> by git-version-gen.
>
> GNU Inetutils
with annotated tags.
The problem boils down to an issue of tag prefixes,
namely as soon as it is not the default "v", presumed
by git-version-gen.
GNU Inetutils prefers the tag prefix "inetutils-", so we
use the preparator
build_aux/git-version-gen .tarball-version 's
On 13/04/15 23:04, Mats Erik Andersson wrote:
> Hello there,
>
> I have for some time been disturbed by the fact that 'git-version-gen'
> relies on the presence of an annotated tag in order to pick a good
> revision string. The following patch is adding a mechani
Hello there,
I have for some time been disturbed by the fact that 'git-version-gen'
relies on the presence of an annotated tag in order to pick a good
revision string. The following patch is adding a mechanism to use
the call 'git describe --always' as the very last resort,
On 12/01/2014 10:55 PM, KO Myung-Hun wrote:
> Subject: [PATCH] git-version-gen: do not print new line characters
>
> * build-aux/git-version-gen: Use printf instead of echo and tr.
This commit message says what, but lacks why; the next reader might
appreciate knowing that some versions
Hi/2.
Paul Eggert wrote:
> Sorry, I forgot to CC: this one to you.
>
>
> Forwarded Message
> Subject: Re: [PATCH 03/21] git-version-gen: remove CR as well
> Date: Sun, 30 Nov 2014 08:41:03 -0800
> From: Paul Eggert
> Organization: UCLA Computer Scie
On 11/29/2014 09:20 PM, KO Myung-Hun wrote:
> On OS/2, a new line consists of CR and LF.
>
> * build-aux/git-version-gen: Remove CR as well.
> ---
> build-aux/git-version-gen | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/build-aux/git-ver
KO Myung-Hun wrote:
+echo "$v" | tr -d "$cr$nl"
How about this instead?
printf '%s' "$v"
This avoids the need for cr and for tr, which is simpler and a bit faster. The
script is already using printf so this shouldn't be a portability issue.
On OS/2, a new line consists of CR and LF.
* build-aux/git-version-gen: Remove CR as well.
---
build-aux/git-version-gen | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 47d6576..77fb2ad 100755
--- a/build-aux/git
On Mon, 22 Sep 2014 09:22:07 -0600, Eric Blake wrote:
> Sadly, this won't work. There's no easily portable way to specify a raw
> carriage return in scripting
If your system has printf (which is in POSIX and widely supported),
you could do this to set variable "cr" to carriage return (since prin
[adding gnulib]
On 09/22/2014 12:59 AM, KO Myung-Hun wrote:
> * build-aux/git-version-gen: Subject.
> ---
> build-aux/git-version-gen |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
> i
On 06/19/2014 11:25 PM, Alfred M. Szmidt wrote:
> Seeing that --prefix and --fallback have a mandatory argument, it
> should be mentioned in --help. The following patch does that.
>
> diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
> @@ -85,8 +85,9 @@ Print a
Seeing that --prefix and --fallback have a mandatory argument, it
should be mentioned in --help. The following patch does that.
diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 0278a9c..47d6576 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6
On Tue, Jun 10, 2014 at 8:47 AM, Phillip Susi wrote:
> I tried making a release candidate by appending -rc1 to the normal version
> number, and it seems that this makes git-version-gen puke and come up with
> UNKNOWN as the version. It looks like it has some code for dealing with old
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I tried making a release candidate by appending -rc1 to the normal version
number, and it seems that this makes git-version-gen puke and come up with
UNKNOWN as the version. It looks like it has some code for dealing with old
versions of git
ersion string.
Otherwise, I would be just happy with 0.99.91 or so.
> [...] he included "support" in automake for the extra gnits checks
> we were thinking about. That is all.
Well, some tests are quite useful. It's just the version number
checking that I consider... limited.
For NTP, we have a kinda hard to describe but easy to read mechanism.
For development versions (odd-number minor releases) each new "issue"
gets a bumped "point number" (major.minor.point). If that issue is a
release candidate it gets a "-RC" suffix.
For stable versions (even-number minor releas
1.00rc0
Personally, when I see a version number like that, I'm never sure what
it means. Probably the first rc leading up to 1.00, but maybe it is an
rc for 1.01 after 1.00. And suffixes sort badly in long lists (see,
e.g., http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change
your
Folks,
I try to make a release candidate. Theoretically, I could use version
`0.99.99' or something similar, however, it looks much nicer IMHO to
use `1.00rc0'. Unfortunately, the gnits standard currently prevents
this. To be more precise, it's the following regex in the automake
script:
m
1 - 100 of 224 matches
Mail list logo
