Re: [lmi] git describe (was: [lmi-commits] master 783f4dd 5/9: Consolidate and revise documentation)

[Vadim Zeitlin]

On Sat, 28 Apr 2018 19:45:16 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-04-28 16:39, Vadim Zeitlin wrote:
GC> > On Sat, 28 Apr 2018 01:22:34 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Okay, I've tried to do that for class wx_table_generator::column_info
GC> > GC> in commit c9f958f6cb904.
GC> > 
GC> >  Sorry, I don't see any such commit. Is it not pushed yet or did you mean 
a
GC> > different commit perhaps?
GC> 
GC> This looks really frightening,

 No, not really.

GC> 'xanadu' being my alias for github, where I have no account and cannot
GC> have committed anything:
GC> 
GC>   /opt/lmi/src/lmi[0]$git describe --all c9f958f6cb904
GC>   remotes/xanadu/master-22-gc9f958f6

 This just means that this commit has xanadu/master as its ancestor 22
times removed (23rd grandparent unless I'm off by one and it's 22nd or 24th
one...).

GC> I had committed c9f958f6cb904 and copied that SHA1 into my email.
GC> Then, reviewing the commit one last time before pushing, I saw a
GC> one-character typing mistake, and fixed it:
GC> 
GC>   /opt/lmi/src/lmi[0]$git commit --amend
GC>   ...
GC>   [master 2dd92c91] Move most commentary out of a class declaration

 You probably know it already, but, just to be sure: amending changes the
commit message and, unless you used "-c HEAD" explicitly, also commit
timestamp. Both are inputs to the hashing algorithm producing Git commit
hashes, so it's not surprising that amending changes the hash.

GC> As for this mystery:
GC> 
GC>   /opt/lmi/src/lmi[0]$git describe --all c9f958f6cb904
GC>   remotes/xanadu/master-22-gc9f958f6
GC> 
GC> I don't know why git-describe says that.

 It just looks for the closest symbolic name to the commit given as its
argument. And it happens to be this one.

GC> It seems unlikely that we've found a collision on a 13-character SHA1
GC> between savannah and github

 No, there is no collision, I'm not sure why do you think there would be
one.

GC> I can only guess that '--amend' causes the old SHA1 to become invalid
GC> for purposes of 'git describe', which then returns a meaningless string.

 Amending creates a new commit with the new SHA-1, but the old commit (and
hence its SHA-1) still exists, unless it's garbage-collected. And the
string returned by git-describe is not meaningless at all, just not very
helpful. It's really meant to be used with tags, so that you could easily
see which release a commit is based on. But lmi doesn't use tags as it
relies on the dates (of its monthly releases instead). Personally, I'd
prefer to still tag the releases, but it's a conversation for another
day...

 In the meanwhile, I hope I could have reassured you. But please let me
know if I failed to dispel your dread and if anything still seems
mysterious here,
VZ