The 'todo' sheet for interactive rebase shows abbreviated SHA-1's and
then performs its operations upon those shortened values. This can lead
to an abort if the SHA-1 of a reworded or edited commit is no longer
unique within the abbreviated SHA-1 space and a subsequent SHA-1 in the
todo list has the same abbreviated value.

For example:

  edit f00dfad first
  pick badbeef second

If, after editing, the new SHA-1 of "first" is now
badbeef5ba78983324dff5265c80c4490d5a809a, then the subsequent 'pick
badbeef second' will fail since badbeef is no longer a unique SHA-1

  error: short SHA1 badbeef is ambiguous.
  fatal: Needed a single revision
  Invalid commit name: badbeef

Demonstrate this problem with a couple of specially crafted commits
which initially have distinct abbreviated SHA-1's, but for which the
abbreviated SHA-1's collide after a simple rewording of the first
commit's message.

Signed-off-by: Eric Sunshine <>
 t/ | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/t/ b/t/
index af141be..e5ebec6 100755
--- a/t/
+++ b/t/
@@ -977,4 +977,21 @@ test_expect_success 'rebase -i with --strategy and -X' '
        test $(cat file1) = Z
+test_expect_success 'short SHA-1 setup' '
+       test_when_finished "git checkout master" &&
+       git checkout --orphan collide &&
+       git rm -rf . &&
+       unset test_tick &&
+       test_commit collide1 collide &&
+       test_commit --notick collide2 collide &&
+       test_commit --notick "collide3 115158b5" collide collide3 collide3
+test_expect_failure 'short SHA-1 collide' '
+       test_when_finished "reset_rebase && git checkout master" &&
+       git checkout collide &&
+       FAKE_COMMIT_MESSAGE="collide2 815200e" \
+       FAKE_LINES="reword 1 2" git rebase -i HEAD~2

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to