Discussion:
[PATCH] git-version-gen: Fix for tags containing '-'
(too old to reply)
Markus Armbruster
2017-08-06 06:26:03 UTC
Permalink
Raw Message
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-gen
recognizes both patterns, and normalizes the old format to the new
one.

Unfortunately, this normalization code gets confused when the tag
contains '-'. Reproducer:

$ git-tag -m test v0.2-rc1
$ build-aux/git-version-gen .tarball-version; echo
build-aux/git-version-gen: WARNING: git rev-list failed
UNKNOWN

We take exact tag "v0.2-rc1" for the old format, extract the presumed
tag "v0.2" from it, then run "git rev-list v0.2..HEAD" to count
commits since tha tag. Fails, because tag "v0.2" does not exist.

We could perhaps drop support for versions from more than a decade
ago. But tightening the pattern match is easy enough, so do that.
Still breaks when you use version tags ending in something matching
-g????, but you arguably get what you deserve then.

Signed-off-by: Markus Armbruster <***@pond.sub.org>
---
build-aux/git-version-gen | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/build-aux/git-version-gen b/build-aux/git-version-gen
index 079849d..6c054b4 100755
--- a/build-aux/git-version-gen
+++ b/build-aux/git-version-gen
@@ -1,6 +1,6 @@
#!/bin/sh
# Print a version string.
-scriptversion=2017-01-09.19; # UTC
+scriptversion=2017-08-06.05; # UTC

# Copyright (C) 2007-2017 Free Software Foundation, Inc.
#
@@ -168,8 +168,8 @@ then
# Newer: v6.10-77-g0f8faeb
# Older: v6.10-g0f8faeb
case $v in
- *-*-*) : git describe is okay three part flavor ;;
- *-*)
+ *-*-g????) : git describe is okay three part flavor ;;
+ *-g????)
: git describe is older two part flavor
# Recreate the number of commits and rewrite such that the
# result is the same as if we were using the newer version
--
2.7.5
Jim Meyering
2017-08-06 16:04:53 UTC
Permalink
Raw Message
Post by Markus Armbruster
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-gen
recognizes both patterns, and normalizes the old format to the new
one.
Unfortunately, this normalization code gets confused when the tag
$ git-tag -m test v0.2-rc1
$ build-aux/git-version-gen .tarball-version; echo
build-aux/git-version-gen: WARNING: git rev-list failed
UNKNOWN
We take exact tag "v0.2-rc1" for the old format, extract the presumed
tag "v0.2" from it, then run "git rev-list v0.2..HEAD" to count
commits since tha tag. Fails, because tag "v0.2" does not exist.
We could perhaps drop support for versions from more than a decade
ago. But tightening the pattern match is easy enough, so do that.
Still breaks when you use version tags ending in something matching
-g????, but you arguably get what you deserve then.
Hi Markus!

Thank you for that patch.
I've tweaked the commit log, copied it into the ChangeLog file and pushed.
Paul Eggert
2017-08-06 16:22:58 UTC
Permalink
Raw Message
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.
Jim Meyering
2017-08-06 18:18:49 UTC
Permalink
Raw Message
Post by Paul Eggert
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.
Thanks for the quick fix.
Markus Armbruster
2017-08-06 18:46:16 UTC
Permalink
Raw Message
Post by Paul Eggert
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 patch works for me. The pattern could
be tightened, but I figure it's good enough as is.

Hmm, 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 '-' in tags. I think it should replace the first '-g'
instead. What do you think?
Paul Eggert
2017-08-06 19:02:17 UTC
Permalink
Raw Message
Post by Markus Armbruster
# 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 '-' in tags. I think it should replace the first '-g'
instead. What do you think?
Sorry, I'm not following. Could you give an example of the problem? Evidently
the code is messing with the first "-" and the last "-g" deliberately.
Markus Armbruster
2017-08-07 05:47:58 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Markus Armbruster
# 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 '-' in tags. I think it should replace the first '-g'
instead. What do you think?
Sorry, I'm not following. Could you give an example of the problem?
Evidently the code is messing with the first "-" and the last "-g"
deliberately.
I was too terse, and not entirely accurate, sorry. Let me try again.

If I understand this code's intent correctly, it tries to change the "-"
separating the tag from the number of additional commits to ".", and the
"-g" separating the number of additional commits from the abbreviated
object name to just "-". Example:

v0.1-1496-gcbc7002

becomes

v0.1.1496-cbc7002

The problem is once again tag names containing "-", because then the
first "-" is *not* the one we want to change.

Example:

$ git-tag -m test v0.2-rc1 HEAD^
$ git-describe
v0.2-rc1-1-gcbc7002
$ build-aux/git-version-gen .tarball-version; echo
0.2.rc1-1-cbc700

We change 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)
$ git-describe
v0.2-rc1
$ build-aux/git-version-gen .tarball-version; echo
0.2.rc1

There is no number of commits to change. We change the tag name
instead.

Should we replace /-([^-]+)-g([^-]*)$/ by /.\1-\2/? Extended regexp
for clarity. Tighter matching would be possible, say
/-([0-9]+)-g[0-9a-f]{4,}$/.
Paul Eggert
2017-08-07 06:30:19 UTC
Permalink
Raw Message
Post by Markus Armbruster
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.
Markus Armbruster
2017-08-07 08:14:38 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Markus Armbruster
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!

Loading...