Re: gnulib-tool --version

[Bob Proulx]

Eric Blake wrote:
> What is really needed is a method in git where once a SHA1 prefix becomes
> ambiguous, you can still easily choose to resolve the ambiguity in favor
> of the oldest commit that matches the prefix.  This is on the grounds that
> there are times when the user knows that the prefix was generated by 'git
> describe', and was not ambiguous at the time it was abbreviated.

Things are a little worse in the presence of merge commits.  In that
case on any branch a rev could have a common prefix with a different
branch.  It is not until they are merged that they become ambiguous.

> Unfortunately, I don't know such a command option or special syntax to
> 'git rev-parse' to make this resolution occur.  And what's worse, the
> error message from 'git rev-parse' doesn't help - it only states that the
> prefix is either missing or ambiguous.  It would be much nicer to know
> that the prefix is now too short (vs. never existed), to then know to try
> the option to list all the alternative candidates and/or pick the oldest.

Agreed.  It is a tough problem.  This may or may not be useful:

 for r in $(git rev-list v0.0 | grep ^7abd4b);do
   echo $r $(git show $r | sed -n '/^Date:/{p;q;}')
 done

 7abd4b912d996d04d3afd46fd190929f852d10e7 Date: Sat, 15 Apr 2000 21:58:37 +0000
 7abd4b240bc7c882a73035f494321855f8876d39 Date: Sat, 16 May 1998 20:26:54 +0000

Bob