[PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[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 <sschuberth@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Junio C Hamano]

Sebastian Schuberth <sschuberth@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 <sschuberth@gmail.com>
> ---

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.


>  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]*)

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Felipe Contreras]

Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@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 <sschuberth@gmail.com>
> > ---
> 
> 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.

-- 
Felipe Contreras

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Felipe Contreras]

On Fri, Sep 6, 2013 at 11:30 PM, David Aguilar <davvid@gmail.com> wrote:
>
> On Sep 6, 2013 7:51 PM, "Felipe Contreras" <felipe.contreras@gmail.com>
> wrote:
>>
>> Junio C Hamano wrote:
>> > Sebastian Schuberth <sschuberth@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 <sschuberth@gmail.com>
>> > > ---
>> >
>> > 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.

>> 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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Sebastian Schuberth]

On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano <gitster@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 <sschuberth@gmail.com>
>> ---
>
> 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?

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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Junio C Hamano]

Sebastian Schuberth <sschuberth@gmail.com> writes:

> On Fri, Sep 6, 2013 at 11:40 PM, Junio C Hamano <gitster@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 <sschuberth@gmail.com>
>>> ---
>>
>> 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.

>> 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?

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Sebastian Schuberth]

On Sat, Sep 7, 2013 at 6:10 PM, Junio C Hamano <gitster@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Junio C Hamano]

Sebastian Schuberth <sschuberth@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.

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Felipe Contreras]

On Sun, Sep 8, 2013 at 12:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sebastian Schuberth <sschuberth@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Sebastian Schuberth]

On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano <gitster@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Felipe Contreras]

On Tue, Sep 10, 2013 at 3:06 AM, Sebastian Schuberth
<sschuberth@gmail.com> wrote:
> On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano <gitster@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Junio C Hamano]

Sebastian Schuberth <sschuberth@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.

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Sebastian Schuberth]

On Tue, Sep 10, 2013 at 5:59 PM, Junio C Hamano <gitster@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Felipe Contreras]

On Sat, Sep 7, 2013 at 11:10 AM, Junio C Hamano <gitster@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

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Kyle J. McKay]

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?

Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated

[Sebastian Schuberth]

On Sat, Sep 7, 2013 at 12:34 AM, Kyle J. McKay <mackyle@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