From: Tay Ray Chuan <hidden> Date: 2016-06-15 22:48:47
Restrict the tags used to generate the version string to those that
begin with "v", since git's tags for git-core (ie. excluding git-gui)
are all of the form "vX.Y...".
This is to avoid using private tags by the user in a clone of the git
code repository, which may break certain machinery (eg. Makefile).
Signed-off-by: Tay Ray Chuan <redacted>
---
Ran into this after tagging a topic branch and running make.
Although a "v.*" match does not guarantee the non-usage of private
tags, I feel it's an acceptable level of accuracy.
After this patch, perhaps we could advertise somewhere to git hackers
that tags beginning with "v" should be avoided.
GIT-VERSION-GEN | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
@@ -12,7 +12,7 @@ if test -f version then VN=$(cat version) || VN="$DEF_VER" elif test -d .git -o -f .git &&- VN=$(git describe --abbrev=4 HEAD 2>/dev/null) &&+ VN=$(git describe --match "v*" --abbrev=4 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;; v[0-9]*)--
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:47
Tay Ray Chuan wrote:
Restrict the tags used to generate the version string to those that
begin with "v"
I like it. Thanks!
since git's tags for git-core (ie. excluding git-gui)
are all of the form "vX.Y...".
git gui’s too, now.
This is to avoid using private tags by the user in a clone of the git
code repository, which may break certain machinery (eg. Makefile).
Not to mention gitk:
set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
if {[package vcompare $git_version "1.6.1"] >= 0} {
This requires ‘git version’ output to have the form
introducing 1.2.3.otherstuff
or there will be errors at startup time.
After this patch, perhaps we could advertise somewhere to git hackers
that tags beginning with "v" should be avoided.
Maybe v[0-9]* would make this problem harder to trip.
Jonathan
From: Jonathan Nieder <hidden> Date: 2016-06-15 22:48:47
Jonathan Nieder wrote:
Tay Ray Chuan wrote:
quoted
since git's tags for git-core (ie. excluding git-gui)
are all of the form "vX.Y...".
git gui’s too, now.
Aggh --- sent early, there. Here is what I meant to say.
Shawn, this helps avoid any stray (annotated) tags the user may have
made, following Tay’s example.
Signed-off-by: Jonathan Nieder <redacted>
---
From: Tay Ray Chuan <hidden> Date: 2016-06-15 22:48:47
On Wed, May 12, 2010 at 7:01 AM, Jonathan Nieder [off-list ref] wrote:
Tay Ray Chuan wrote:
quoted
This is to avoid using private tags by the user in a clone of the git
code repository, which may break certain machinery (eg. Makefile).
Not to mention gitk:
set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
if {[package vcompare $git_version "1.6.1"] >= 0} {
This requires ‘git version’ output to have the form
introducing 1.2.3.otherstuff
or there will be errors at startup time.
Thanks for the heads-up, I'll put that in the patch message.
quoted
After this patch, perhaps we could advertise somewhere to git hackers
that tags beginning with "v" should be avoided.
Maybe v[0-9]* would make this problem harder to trip.
Oh, I didn't know character classes were allows. Sounds good.
--
Cheers,
Ray Chuan
From: Tay Ray Chuan <hidden> Date: 2016-06-15 22:48:47
Restrict the tags used to generate the version string to those that
begin with "v", since git's tags for git-core (ie. excluding git-gui)
are all of the form "vX.Y...".
This is to avoid using private tags by the user in a clone of the git
code repository, which may break certain machinery (eg. Makefile, gitk).
Signed-off-by: Tay Ray Chuan <redacted>
---
Changes from RFC:
- used "v[0-9]*" instead of just "v*"
- mentioned gitk as another piece that may break
GIT-VERSION-GEN | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
@@ -12,7 +12,7 @@ if test -f version then VN=$(cat version) || VN="$DEF_VER" elif test -d .git -o -f .git &&- VN=$(git describe --abbrev=4 HEAD 2>/dev/null) &&+ VN=$(git describe --match "v[0-9]*" --abbrev=4 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;; v[0-9]*)--