Re: Ambiguous sha-1 during a rebase

[Mike Hommey <mh@glandium.org>]

On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:
> I suspect you did:
> 
> $ git rebase -i
> # editor pops up
> # switch to another terminal and fetch from elsewhere
> # close editor

That's possible, but I don't remember with certainty. At least it's
plausible.

> Then only, git turns short sha1s into long ones, and does not have the
> information to resolve ambiguities.
> 
> We could save a map (short -> long) before poping the editor and use
> this map in priority when normalizing the todo-list to use long sha1s,
> but we currently don't.
> 
> But I'm tempted to say that you just went very, very unlucky, and it's
> not worth fixing ...

Yeah, that definitely is a weird corner case. Interestingly, it was
complaining about "error: short SHA1 e34ff55 is ambiguous." when apply
*other* commits that were in the list prior to it, and then had the
fatal error when it reached it.

That said, that would be less likely to happen if disambiguation was
also checking checking the object type. Collisions between commits are
less likely than between objects of different types.

As a matter of fact, of the 293143 commits in my repository, only 156
have collisions with other commits (0.05%), but when comparing them to
all the 3260854 objects in the repository, I see 3545 have collisions
(1.2%).

Mike