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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
