summaryrefslogtreecommitdiff
path: root/t
diff options
context:
space:
mode:
authorLibravatar Johannes Schindelin <johannes.schindelin@gmx.de>2020-01-23 12:28:18 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-01-23 12:48:11 -0800
commitb6992261deb1c32e11998b19467ecd4d328ba049 (patch)
tree8b7fae5125f889a66b01abc2e1a173322e4e4e75 /t
parentparse_insn_line(): improve error message when parsing failed (diff)
downloadtgif-b6992261deb1c32e11998b19467ecd4d328ba049.tar.xz
rebase -i: re-fix short SHA-1 collision
In 66ae9a57b88 (t3404: rebase -i: demonstrate short SHA-1 collision, 2013-08-23), we added a test case that demonstrated how it is possible that a previously unambiguous short commit ID could become ambiguous *during* a rebase. In 75c69766554 (rebase -i: fix short SHA-1 collision, 2013-08-23), we fixed that problem simply by writing out the todo list with expanded commit IDs (except *right* before letting the user edit the todo list, in which case we shorten them, but we expand them right after the file was edited). However, the bug resurfaced as a side effect of 393adf7a6f6 (sequencer: directly call pick_commits() from complete_action(), 2019-11-24): as of this commit, the sequencer no longer re-reads the todo list after writing it out with expanded commit IDs. The only redeeming factor is that the todo list is already parsed at that stage, including all the commits corresponding to the commands, therefore the sequencer can continue even if the internal todo list has short commit IDs. That does not prevent problems, though: the sequencer writes out the `done` and `git-rebase-todo` files incrementally (i.e. overwriting the todo list with a version that has _short_ commit IDs), and if a merge conflict happens, or if an `edit` or a `break` command is encountered, a subsequent `git rebase --continue` _will_ re-read the todo list, opening an opportunity for the "short SHA-1 collision" bug again. To avoid that, let's make sure that we do expand the commit IDs in the todo list as soon as we have parsed it after letting the user edit it. Additionally, we improve the 'short SHA-1 collide' test case in t3404 to test specifically for the case where the rebase is resumed. We also hard-code the expected colliding short SHA-1s, to document the expectation (and to make it easier on future readers). Note that we specifically test that the short commit ID is used in the `git-rebase-todo.tmp` file: this file is created by the fake editor in the test script and reflects the state that would have been presented to the user to edit. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't')
-rwxr-xr-xt/t3404-rebase-interactive.sh15
1 files changed, 13 insertions, 2 deletions
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index ae6e55ce79..1cc9f36bc7 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1264,13 +1264,24 @@ test_expect_success SHA1 'short SHA-1 setup' '
test_expect_success SHA1 'short SHA-1 collide' '
test_when_finished "reset_rebase && git checkout master" &&
git checkout collide &&
+ colliding_sha1=6bcda37 &&
+ test $colliding_sha1 = "$(git rev-parse HEAD | cut -c 1-7)" &&
(
unset test_tick &&
test_tick &&
set_fake_editor &&
FAKE_COMMIT_MESSAGE="collide2 ac4f2ee" \
- FAKE_LINES="reword 1 2" git rebase -i HEAD~2
- )
+ FAKE_LINES="reword 1 break 2" git rebase -i HEAD~2 &&
+ test $colliding_sha1 = "$(git rev-parse HEAD | cut -c 1-7)" &&
+ grep "^pick $colliding_sha1 " \
+ .git/rebase-merge/git-rebase-todo.tmp &&
+ grep "^pick [0-9a-f]\{40\}" \
+ .git/rebase-merge/git-rebase-todo &&
+ git rebase --continue
+ ) &&
+ collide2="$(git rev-parse HEAD~1 | cut -c 1-4)" &&
+ collide3="$(git rev-parse collide3 | cut -c 1-4)" &&
+ test "$collide2" = "$collide3"
'
test_expect_success 'respect core.abbrev' '