Re: sporadic git failures on interactive rebase

From: Jeff King <peff@peff.net>
Date: Jan 14, 2015, 12:19 UTC
Message-ID: <20150114121915.GB30383@peff.net>
In-Reply-To: <trinity-5098e61e-b59a-4225-9d4c-8879dc78bb53-1421146472532@3capp-gmx-bs08>

On Tue, Jan 13, 2015 at 11:54:32AM +0100, Henning Moll wrote:

Show 13 quoted lines

> . error: short SHA1 c4095c1 is ambiguous.
> . fatal: Needed a single revision
> . Invalid commit name: c4095c1
> 
> Now that the command failed, i checked for ambigous c4095c1. But there is only one:
> $ git log -1 c4095c1
> . commit c4095c1f5e7c126accf93ba68e2fa72bb055f567
> . ...
> 
> Just as a test:
> $ git log -1 c409
> . error: short SHA1 c409 is ambiguous.
> . error: short SHA1 c409 is ambiguous.

Hmm. There are some instances in git where we know we are looking for an object of a particular type, and we can disambiguate a short-sha1 based on the type. And "git log" is just such a place, whereas a generic "git rev-parse" used by the git-rebase script would not be.

Try:

  git rev-list --objects --all |
  grep ^c4095c1 |
  cut -d' ' -f1 |
  git cat-file --batch-check

If my hunch is right, then you may find multiple objects, only one of which is a commit.

And if so, the solution is likely one of:

  1. Teach rev-parse a "prefer committish" option and use it in the
     appropriate spot in git-rebase.

  2. Teach whatever is generating the shortended sha1s to report a truly
     unambiguous result, not one that depends on the type. I don't think
     we _have_ a codepath to do type-dependent shortening, though, which
     is maybe an indication that this is a red herring.

It's also possible that part of the rebase sequence generates a new object that creates the ambiguity. That would be consistent with your statement that rolling back and running the commands again makes it work. I'm not sure how to defend against that, aside from adding a character or two to the shortened ids, which reduces the likelihood of a collision.

-Peff