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
