git/t/t3429-rebase-edit-todo.sh

56 lines
1.5 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='rebase should reread the todo file if an exec modifies it'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-rebase.sh
test_expect_success 'setup' '
test_commit first file &&
test_commit second file &&
test_commit third file
'
test_expect_success 'rebase exec modifies rebase-todo' '
todo=.git/rebase-merge/git-rebase-todo &&
git rebase HEAD -x "echo exec touch F >>$todo" &&
test -e F
'
test_expect_success 'loose object cache vs re-reading todo list' '
rebase -i: demonstrate obscure loose object cache bug We specifically support `exec` commands in `git rebase -i`'s todo lists to rewrite the very same todo list. Of course, we need to validate that todo list when re-reading it. It is also totally legitimate to extend the todo list by `pick` lines using short names of commits that were created only after the rebase started. And this is where the loose object cache interferes with this feature: if *some* loose object was read whose hash shares the same first two digits with a commit that was not yet created when that loose object was created, then we fail to find that new commit by its short name in `get_oid()`, and the interactive rebase fails with an obscure error message like: error: invalid line 1: pick 6568fef error: please fix this using 'git rebase --edit-todo'. Let's first demonstrate that this is actually a bug in a new regression test, in a separate commit so that other developers who do not believe me can cherry-pick it to confirm the problem. This new regression test generates two commits whose hashes share the first two hex digits (so that their corresponding loose objects live in the same subdirectory of .git/objects/, and are therefore supposed to be in the same loose object cache bin). It then picks the first, to make sure that the loose object cache is initialized and cached that object directory, then generates the second commit and picks it, too. Since the commit was generated in a different process than the sequencer that wants to pick it, the loose object cache had no chance of being updated in the meantime. Technically, we would need only one `exec` command in this regression test case, but for ease of implementation, it uses a pseudo-recursive call to the same script. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-13 10:16:31 +00:00
GIT_REBASE_TODO=.git/rebase-merge/git-rebase-todo &&
export GIT_REBASE_TODO &&
write_script append-todo.sh <<-\EOS &&
# For values 5 and 6, this yields SHA-1s with the same first two digits
echo "pick $(git rev-parse --short \
$(printf "%s\\n" \
"tree $EMPTY_TREE" \
"author A U Thor <author@example.org> $1 +0000" \
"committer A U Thor <author@example.org> $1 +0000" \
"" \
"$1" |
git hash-object -t commit -w --stdin))" >>$GIT_REBASE_TODO
shift
test -z "$*" ||
echo "exec $0 $*" >>$GIT_REBASE_TODO
EOS
git rebase HEAD -x "./append-todo.sh 5 6"
'
test_expect_success 'todo is re-read after reword and squash' '
write_script reword-editor.sh <<-\EOS &&
GIT_SEQUENCE_EDITOR="echo \"exec echo $(cat file) >>actual\" >>" \
git rebase --edit-todo
EOS
test_write_lines first third >expected &&
set_fake_editor &&
GIT_SEQUENCE_EDITOR="$EDITOR" FAKE_LINES="reword 1 squash 2 fixup 3" \
GIT_EDITOR=./reword-editor.sh git rebase -i --root third &&
test_cmp expected actual
'
test_done