On Wed, Jan 14, 2015 at 07:19:15AM -0500, Jeff King wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html