Re: Ambiguous sha-1 during a rebase

From: Mike Hommey <mh@glandium.org>
Date: Apr 14, 2016, 09:38 UTC
Message-ID: <20160414093847.GA10852@glandium.org>
In-Reply-To: <vpqr3e8wo99.fsf@anie.imag.fr>

On Thu, Apr 14, 2016 at 11:09:06AM +0200, Matthieu Moy wrote:

Show 6 quoted lines

> 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.

Show 9 quoted lines

> 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