Re: Referring to revisions in the git future.

[David Kastrup <dak@gnu.org>]

Werner LEMBERG <wl@gnu.org> writes:

>> FWIW I have basically never used Bzr's revno in conversations.
>> There's no question that they're handy, and I've used them, but I
>> think that dates work well enough in practice as a replacement (with
>> pretty much the same downsides).  Just replace
>> 
>>     "That was fixed in revision 118147, have you updated since then?"
>> with
>>     "That was fixed on Sep 23, have you updated since then?"
>
> `git describe' and/or `git describe --tags' returns sequential
> numbers, more or less.  It's essentially a tool to do the opposite,
> this is, showing the most recent tag that is reachable from a given
> commit, but it contains the number of commits in its return value.

dak@lola:/usr/local/tmp/lilypond$ git describe
release/2.19.15-1-52-g0c59175

Seriously.  Ok, this is 52 commits after tag release/2.19.15-1
(obviously, a tag naming scheme that does not help readability), and it
turns out that the commit id is 0c59175f0867663196e77061786dc07708d69894
so that is where the g... part is from.

But I am still hard put to consider this more useful for any purpose.
It's either some hand-waving relation to the last tag, or you could have
been using the SHA1 in the first place.

One can actually feed such an id into git but it would appear that git
_only_ looks at the trailing g0c59175 string and that becomes invalid as
soon as there is another commit id starting with 0c59175.  While the
abbreviated commit id is guaranteed to be unique in the _current_
repository, it may no longer be once stuff is added to it.  Or even if
the person you send release/2.19.15-1-52-g0c59175 to happens to have a
commit id starting with 0c59175 in a private branch of his.

Such an id is probably nice as a version number string since then
developers might be able to put the version into a rough ballpark
without looking more closely.

But for communicating about particular commits, just using the SHA1
seems much less problematic.

-- 
David Kastrup