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 also has prefix badbeef,
then the subsequent 'pick badbeef second' will fail since badbeef is no
longer a unique SHA-1 abbreviation:
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 sunsh...@sunshineco.com
---
t/t3404-rebase-interactive.sh | 24
1 file changed, 24 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index f857161..64a02a0 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1037,4 +1037,28 @@ 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 collide
+ )
+'
+
+test_expect_failure 'short SHA-1 collide' '
+ test_when_finished reset_rebase git checkout master
+ git checkout collide
+ (
+ unset test_tick
+ test_tick
+ set_fake_editor
+ FAKE_COMMIT_MESSAGE=collide2 ac4f2ee \
+ FAKE_LINES=reword 1 2 git rebase -i HEAD~2
+ )
+'
+
test_done
--
1.8.4.557.g34b3a2e
--
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