Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano gits...@pobox.com wrote: 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? 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. 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? 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. 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. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Tue, Sep 10, 2013 at 3:06 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano gits...@pobox.com wrote: 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. 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes: 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Tue, Sep 10, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote: 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. Fair enough! -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes: 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? 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. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sun, Sep 8, 2013 at 12:41 PM, Junio C Hamano gits...@pobox.com wrote: Sebastian Schuberth sschube...@gmail.com writes: 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? 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. 'version' works, there's no need for DEF_VER. 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. 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sat, Sep 7, 2013 at 12:34 AM, Kyle J. McKay mack...@gmail.com wrote: 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. 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. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano gits...@pobox.com wrote: 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 sschube...@gmail.com --- H, 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? That's not sufficient if you care about a proper (automated) release workflow with your releases tagged. 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. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes: On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano gits...@pobox.com wrote: 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 sschube...@gmail.com --- H, 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. 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sat, Sep 7, 2013 at 6:10 PM, Junio C Hamano gits...@pobox.com wrote: 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. 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. 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. 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. 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? 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. 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. -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sat, Sep 7, 2013 at 11:10 AM, Junio C Hamano gits...@pobox.com wrote: 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? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Fri, Sep 6, 2013 at 11:30 PM, David Aguilar dav...@gmail.com wrote: On Sep 6, 2013 7:51 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Junio C Hamano wrote: Sebastian Schuberth sschube...@gmail.com writes: 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 sschube...@gmail.com --- H, 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. 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. 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 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.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b444c18..68b61e3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -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]*)
--
1.8.3.msysgit.1.3.g5b82b42.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes:
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 sschube...@gmail.com
---
H, 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.
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b444c18..68b61e3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -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]*)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sep 6, 2013, at 13:10, Sebastian Schuberth wrote: 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Junio C Hamano wrote: Sebastian Schuberth sschube...@gmail.com writes: 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 sschube...@gmail.com --- H, 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
