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

Re: [RFC] Is using git describe resilient enough for setting the build version of git?

From
Avery Pennarun <apenwarr@gmail.com>
Date
Feb 21, 2010, 06:07 UTC
Message-ID
<32541b131002202207s7e9794cdg94d4bc305a0e9213@mail.gmail.com>
In-Reply-To
<4B8082ED.7020505@think.zenbe.com>
On Sat, Feb 20, 2010 at 7:48 PM, Steve Diver <squelch@think.zenbe.com> wrote:
Show 11 quoted lines
> Reading the manual entry for "git describe"[1] there is a note saying that
> the hash suffix does not guarantee disambiguity, and given that a tag may be
> incorrect or missing, there is a chance - albeit with diminishing odds -
> that the 5 digit hash/tag combination might lead to some obscure problems at
> some point along the line.
>
> The chance of this happening really is low, but there is a chance all the
> same. We cannot foresee all errors, but identifying, and further reducing
> the odds of some must be good. Without doing the math, a guess would be that
> the probability of a repeat 5 digit abbreviated hash suffix increases the
> longer a tagged version is in place, so never will be 100% safe.

Not really. Note that the number *before* the hash is the number of commits between your version and the tag. So the only way to get an actual undetectable overlap would be to have two commits that are both the same number of commits on top of the given tag, *and* both start with the same first five digits. It's just not very likely at all. Besides which, using the hash code feature of git-describe is most useful for the short periods between versions, not as a long-term thing. After a new release comes out it's unlikely anyone will care if the previous hash prefixes were overlapping.

Show 8 quoted lines
> I may be wrong, but the only scenario where I see DEF_VER being used by
> GIT-VERSION-GEN, would be when there are no tags for git describe to
> retrieve. ie "git pull --no-tags"
>
> If my understanding is correct, DEF_VER is unique and set at the same time
> as the tagged version, so wouldn't it be desirable to cross check, or
> include this value instead of relying solely on the tag when present during
> the generation of GIT-VERSION-FILE at build time?

If I recall correctly, the main reason for DEF_VER is when building git from a tarball, in which case 'git describe' wouldn't be able to tell you anything useful.

Have fun,
Avery
Previous: Steve DiverNext: Steve Diver
Message 2 of 3 in “[RFC] Is using git describe resilient enough for setting the build version of git?”
  1. Steve DiverFeb 21, 2010
  2. Avery PennarunFeb 21, 2010
  3. Steve DiverFeb 21, 2010

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.