git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 7, 2013, 16:10 UTC
Message-ID
<xmqqsixgvci1.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CAHGBnuP6w8rvoz+h2Xase1ApY_kpZh4X=VF6LY4O0r7RS0UayA@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
Show 11 quoted lines
> 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.
Show 8 quoted 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?

Previous: Sebastian SchuberthNext: Sebastian Schuberth
Message 5 of 16 in “GIT-VERSION-GEN: Do not require tags to be annotated”
  1. GIT-VERSION-GEN: Do not require tags to be annotatedSebastian Schuberth, Sep 6, 2013
  2. Junio C HamanoSep 6, 2013
  3. Felipe ContrerasSep 7, 2013
  4. Sebastian SchuberthSep 7, 2013
  5. Junio C HamanoSep 7, 2013
  6. Sebastian SchuberthSep 7, 2013
  7. Junio C HamanoSep 8, 2013
  8. Felipe ContrerasSep 9, 2013
  9. Sebastian SchuberthSep 10, 2013
  10. Felipe ContrerasSep 10, 2013
  11. Junio C HamanoSep 10, 2013
  12. Sebastian SchuberthSep 10, 2013
  13. Felipe ContrerasSep 8, 2013
  14. Kyle J. McKaySep 6, 2013
  15. Sebastian SchuberthSep 7, 2013
  16. Felipe ContrerasSep 8, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.