Re: sporadic git failures on interactive rebase

From: Jeff King <peff@peff.net>
Date: Jan 14, 2015, 12:35 UTC
Message-ID: <20150114123536.GA31530@peff.net>
In-Reply-To: <20150114121915.GB30383@peff.net>

On Wed, Jan 14, 2015 at 07:19:15AM -0500, Jeff King wrote:

Show 8 quoted lines

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

Yeah, I think this cannot be it. There is a 7-character commit/blob ambiguity in git. You can find it yourself with:

  git rev-list --objects --all |
  cut -d' ' -f1 |
  sort | uniq -w 7 -D |
  git cat-file --batch-check |
  head -2

which produces:

  01319837c53050109c60e6740dfa9462327161f0 commit 649
  0131983dfbc143ce5dae77e067663bb2e7d5f126 blob 20638

And it behaves as expected. Running "git rev-parse 0131983" complains of the ambiguity, but "git log 0131983" shows the commit.

What happens if we rebase with it?

  $ git checkout 01319837
  $ git rebase -i HEAD^

will yield a todo file with the 8-character unambiguous abbreviation.

So I guess all is working as intended there. Perhaps you really were just very unlucky and an earlier step of the rebase created a conflicting sha1.

-Peff