GIT-VERSION-GEN: Do not require tags to be annotated
PATCH 1/1 GIT-VERSION-GEN: Do not require tags to be annotated
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
--- GIT-VERSION-GEN | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
GIT-VERSION-GEN +1 -1
@@ -12,7 +12,7 @@ if test -f version then VN=$(cat version) || VN="$DEF_VER" elif test -d ${GIT_DIR:-.git} -o -f .git && - VN=$(git describe --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) && + VN=$(git describe --tags --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;; v[0-9]*)
Signature · 1 line
1.8.3.msysgit.1.3.g5b82b42.dirty
Quoted 2 lines · Sebastian Schuberth
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
It's not that hard to add -m "" to the command line:
git tag -a -m "" new-annotated-tag
if you're just trying to avoid the editor or thinking up a message. Is -m "" really that inconvenient?
Quoted 4 lines · Kyle J. McKay
Quoted 2 lines
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
It's not that hard to add -m "" to the command line:
It's not hard to type those characters, but (for me) it's hard to remember that I have to do it.
Quoted 2 lines
if you're just trying to avoid the editor or thinking up a message. Is
-m ""really that inconvenient?
Yes, to me it's inconvenient, but not that much. And I think passing an empty annotation like you suggest is even worse than not setting an annotation at all, because I would assume if an annotation is set it's not empty, and if it is, I would expect this to be a user error.
Signature · 1 line
Sebastian Schuberth
Quoted 5 lines · Sebastian Schuberth
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
Signed-off-by Sebastian Schuberth <[email protected]>---
Hmmmm, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag.
If you want to give build a custom name,
echo buildname >version
should be sufficient, no?
I dunno.
Quoted 16 lines
GIT-VERSION-GEN | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)GIT-VERSION-GEN +1
-1@@ -12,7 +12,7 @@ if test -f version then VN=$(cat version) || VN="$DEF_VER" elif test -d ${GIT_DIR:-.git} -o -f .git && - VN=$(git describe --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) && + VN=$(git describe --tags --match "v[0-9]*" --abbrev=7 HEAD 2>/dev/null) && case "$VN" in *$LF*) (exit 1) ;; v[0-9]*)
Quoted 11 lines · Junio C Hamano
Quoted 5 lines · Sebastian Schuberth
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
Signed-off-by Sebastian Schuberth <[email protected]>---
Hmmmm, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag.
So the only user Git should care about is you? If Git can make _you_ more confortable not making certain mistakes, then that's the way it should be?
What's the point of lightweight tags anyway? 'git describe' doesn't use them, GIT-VERSION-GEN neither, just remove them already.
For the vast majority of the people out there, a tag is a tag. Period.
Signature · 1 line
Felipe Contreras
A message that is not in the archive (sent off-list or not yet received): CAJDDKr4JBeccwuD4PVq0ryO27Eyfz+yUAHT7xm0Dkh19SZpV4g@mail.gmail.com
Quoted 14 lines · David Aguilar
Quoted 11 lines · Felipe Contreras
Quoted 9 lines · Junio C Hamano
Quoted 6 lines · Sebastian Schuberth
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
Signed-off-by Sebastian Schuberth <[email protected]>---
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Hmmmm, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag.
So the only user Git should care about is you? If Git can make _you_ more confortable not making certain mistakes, then that's the way it should be?
Yes, certainly. Why would you think otherwise?
The whole purpose of a public software project is that it's useful to others.
Quoted 5 lines
Quoted 3 lines
What's the point of lightweight tags anyway? 'git describe' doesn't use them,
GIT-VERSION-GEN neither, just remove them already.RTFM
I don't see anything in the manual explaining why lightweight tags are useful, if all the Git tools just ignore them, and why the do that.
Quoted 3 lines
Quoted 1 line
For the vast majority of the people out there, a tag is a tag. Period.
Not for me. You are wrong.
You are not the vast majority, you are a single person.
Signature · 1 line
Felipe Contreras
Quoted 10 lines · Junio C Hamano
Quoted 5 lines
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
Signed-off-by Sebastian Schuberth <[email protected]>---
Hmmmm, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag.
Quoted 5 lines
If you want to give build a custom name,
echo buildname >version
should be sufficient, no?
That's not sufficient if you care about a proper (automated) release workflow with your releases tagged.
Quoted 1 line
I dunno.
That's fine, I do not care too deeply about this. I just wanted to give this patch a try and see what others think. Feel free to drop it.
Signature · 1 line
Sebastian Schuberth
Quoted 11 lines · Sebastian Schuberth
Quoted 9 lines · Junio C Hamano
Quoted 5 lines
For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation.
Signed-off-by Sebastian Schuberth <[email protected]>---
Hmmmm, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag.
I do not mind taking the patch after all, after thinking about it a bit more.
See later part of the message for this.
Quoted 8 lines
Quoted 5 lines
If you want to give build a custom name,
echo buildname >version
should be sufficient, no?
That's not sufficient if you care about a proper (automated) release workflow with your releases tagged.
I take the above "your" does not refer to "mine, Junio's".
I am not sure what you mean by automated, but if you can tell your automation infrastructure that the way to build this Git software is to run "make" in it, shouldn't it be trivial to instead tell it to run something like this instead?
git describe --tags HEAD >version && make
Or are these tags you want G-V-G to use also droppings of the automated process? That is, what you tell the automation infrastructure is to run something like this?
git tag build-$(date +"%Y-%m-%d") && make
If that is the case, it would be sufficient to tweak that to leave the same information in >version file and you do not lose any automation.
So I do not understand the above "not sufficient if you care about" comment at all.
Having said all that.
I do not think the current use of "describe" helps the builder to avoid making a light-weight tag by mistake anyway, as it would be very natural to update DEF_VER to a matching string. In a month or so, I am sure I'd update that line to v1.8.5 before I make a tag with the same name, and it does not matter if the current use of "describe" skipped a mistakenly-made lightweight v1.8.5 tag when deciding the embedded version string---the end result will get the same string from DEF_VER and running "git version" with the built binary will happily show v1.8.5 the same way.
I am however still curious what kind of other tags (either signed, annotated, or lightweight) you are using for this purpose. Is there a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag do you want GIT-VERSION-GEN to use?
Quoted 10 lines · Junio C Hamano
Quoted 8 lines
Quoted 5 lines
If you want to give build a custom name,
echo buildname >version
should be sufficient, no?
That's not sufficient if you care about a proper (automated) release workflow with your releases tagged.
I take the above "your" does not refer to "mine, Junio's".
Right, I was not meaning to refer to you personally or Git as a project, but "anyone's project".
Quoted 6 lines
I am not sure what you mean by automated, but if you can tell your automation infrastructure that the way to build this Git software is to run "make" in it, shouldn't it be trivial to instead tell it to run something like this instead?
git describe --tags HEAD >version && make
It probably would be trivial, but I'd like to use as much of upstream Git's build logic as possible without the need to create a custom file.
Quoted 5 lines
Or are these tags you want G-V-G to use also droppings of the automated process? That is, what you tell the automation infrastructure is to run something like this?
git tag build-$(date +"%Y-%m-%d") && make
Sort of. I manually tag a commit as "good for testing", and the CI server that's watching for new tags in the repo then builds my custom Git from that tag and runs the tests. If all tests pass the custom Git binaries are packaged and uploaded to a binary artifact server. I'd like the version that git reports as well as the version that's included in the binary artifact file names to be directly derived from the tag. I simply do not like the idea of having a tag *and* a version file, even if the version file is derived from the tag, simply because there's still a slight chance that the tag and version file might diverge due to some mistake / error / bug.
Quoted 9 lines
I do not think the current use of "describe" helps the builder to avoid making a light-weight tag by mistake anyway, as it would be very natural to update
DEF_VERto a matching string. In a month or so, I am sure I'd update that line to v1.8.5 before I make a tag with the same name, and it does not matter if the current use of "describe" skipped a mistakenly-made lightweight v1.8.5 tag when deciding the embedded version string---the end result will get the same string fromDEF_VERand running "git version" with the built binary will happily show v1.8.5 the same way.
Which raises another question on my side: Isn't it tedious for you to both update DEF_VER *and* tag a version? Wouldn't it probably be less error prove (in the sense of keeping DEF_VER and tagged version in sync) to remove DEF_VER completely and just die if all ways to derive a Git version fail?
Quoted 2 lines
I am however still curious what kind of other tags (either signed, annotated, or lightweight) you are using for this purpose. Is there
In general, so far I had very little use for other tags than lightweight tags. That's mainly because I believe my stuff is not "important" enough to be signed, and I rarely have something to say about a tag besides its name. Most annotate tags I've seen so far are just trivial variations of the tag name, anyway.
Quoted 2 lines
a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag
No. I always carry patches on top.
Signature · 1 line
Sebastian Schuberth
Quoted 5 lines · Sebastian Schuberth
Which raises another question on my side: Isn't it tedious for you to both update
DEF_VER*and* tag a version? Wouldn't it probably be less error prove (in the sense of keepingDEF_VERand tagged version in sync) to removeDEF_VERcompletely and just die if all ways to derive a Git version fail?
I do not see how it will fly well. Some people want to build out of tarballs without having any "describe", and DEF_VER and version were added for that specific purpose.
Quoted 4 lines
Quoted 2 lines
a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag
No. I always carry patches on top.
That answer sidesteps the real issue; which one would you prefer if there are two or more tags? "describe" updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the ">version" thing.
Quoted 9 lines · Junio C Hamano
Quoted 5 lines
Which raises another question on my side: Isn't it tedious for you to both update
DEF_VER*and* tag a version? Wouldn't it probably be less error prove (in the sense of keepingDEF_VERand tagged version in sync) to removeDEF_VERcompletely and just die if all ways to derive a Git version fail?I do not see how it will fly well. Some people want to build out of tarballs without having any "describe", and
DEF_VERand version were added for that specific purpose.
Right, but do we really need DEF_VER *and* version? Couldn't we just package official source tarballs in a way that they already contain an auto-generated version file?
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag
No. I always carry patches on top.
Quoted 7 lines
That answer sidesteps the real issue; which one would you prefer if there are two or more tags? "describe" updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the ">version" thing.
My answer sidesteps the issue because you were explicitly offering the sidestep in you original question ;-) Anyway, in such a scenario I would probably prefer my own tag instead of upstream's tag, to be honest. So you're right that in this case my patch won't help. But like I said, the case is not valid for me as I will always carry patches on top, and other people might feel differently about which tag (annotated vs. lightweight) they prefer if both point to the same commit.
Signature · 1 line
Sebastian Schuberth
Quoted 15 lines · Sebastian Schuberth
Quoted 5 lines · Junio C Hamano
Quoted 4 lines
Quoted 2 lines
a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag
No. I always carry patches on top.
Quoted 7 lines
That answer sidesteps the real issue; which one would you prefer if there are two or more tags? "describe" updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the ">version" thing.
Quoted 8 lines
My answer sidesteps the issue because you were explicitly offering the sidestep in you original question ;-) Anyway, in such a scenario I would probably prefer my own tag instead of upstream's tag, to be honest. So you're right that in this case my patch won't help. But like I said, the case is not valid for me as I will always carry patches on top, and other people might feel differently about which tag (annotated vs. lightweight) they prefer if both point to the same commit.
Indeed. I prefer it the other way; annotated takes precedence.
Signature · 1 line
Felipe Contreras
Quoted 3 lines · Sebastian Schuberth
Right, but do we really need
DEF_VER*and* version? Couldn't we just package official source tarballs in a way that they already contain an auto-generated version file?
If you read our Makefile, you will see that we do include the version file in our official tarball with "make dist".
That however does not help those who use a tarball obtained from git-archive, perhaps via gitweb running at the distribution site.
Theoretically speaking, you can rip out everything but "version" and tell those who have been relying on the way other parts of G-V-G worked to change their workflow to stuff their favorite version string to that file before building, so in that sense, we do not *need* DEF_VER and version. But they have been there for a long time, and I do not think it gives us a good trade-off between risking regression and reducing the linecount to change it to remove one.
Quoted 5 lines · Junio C Hamano
string to that file before building, so in that sense, we do not *need*
DEF_VERand version. But they have been there for a long time, and I do not think it gives us a good trade-off between risking regression and reducing the linecount to change it to remove one.
Fair enough!
Signature · 1 line
Sebastian Schuberth
Quoted 11 lines · Junio C Hamano
Quoted 5 lines · Sebastian Schuberth
Which raises another question on my side: Isn't it tedious for you to both update
DEF_VER*and* tag a version? Wouldn't it probably be less error prove (in the sense of keepingDEF_VERand tagged version in sync) to removeDEF_VERcompletely and just die if all ways to derive a Git version fail?I do not see how it will fly well. Some people want to build out of tarballs without having any "describe", and
DEF_VERand version were added for that specific purpose.
'version' works, there's no need for DEF_VER.
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag
No. I always carry patches on top.
Quoted 7 lines
That answer sidesteps the real issue; which one would you prefer if there are two or more tags? "describe" updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the ">version" thing.
That is a red herring.
If there's a lightweight tag on top of v1.8.4, and Git chooses to use v1.8.4 as a version name, that's fine because as a matter of fact, that's the real version, since there's no actual changes on top of that.
Signature · 1 line
Felipe Contreras
Quoted 6 lines · Junio C Hamano
I am not sure what you mean by automated, but if you can tell your automation infrastructure that the way to build this Git software is to run "make" in it, shouldn't it be trivial to instead tell it to run something like this instead?
git describe --tags HEAD >version && make
Which is a pretty stupid option. 'git describe' does use tags by default anyway, what else is it supposed to do?
Signature · 1 line
Felipe Contreras