t3433: new rebase testcase documenting a stat-dirty-like failure
A user discovered a case where they had a stack of 20 simple commits to
rebase, and the rebase would succeed in picking the first commit and
then error out with a pair of "Could not execute the todo command" and
"Your local changes to the following files would be overwritten by
merge" messages.
Their steps actually made use of the -i flag, but I switched it over to
-m to make it simpler to trigger the bug. With that flag, it bisects
back to commit 68aa495b590d (rebase: implement --merge via the
interactive machinery, 2018-12-11), but that's misleading. If you
change the -m flag to --keep-empty, then the problem persists and will
bisect back to 356ee4659bb5 (sequencer: try to commit without forking
'git commit', 2017-11-24)
After playing with the testcase for a bit, I discovered that added
--exec "sleep 1" to the command line makes the rebase succeed, making me
suspect there is some kind of discard and reloading of caches that lead
us to believe that something is stat dirty, but I didn't succeed in
digging any further than that.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19 20:04:06 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='git rebase across mode change'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
mkdir DS &&
|
|
|
|
>DS/whatever &&
|
|
|
|
git add DS &&
|
|
|
|
git commit -m base &&
|
|
|
|
|
|
|
|
git branch side1 &&
|
|
|
|
git branch side2 &&
|
|
|
|
|
|
|
|
git checkout side1 &&
|
|
|
|
git rm -rf DS &&
|
|
|
|
test_ln_s_add unrelated DS &&
|
|
|
|
git commit -m side1 &&
|
|
|
|
|
|
|
|
git checkout side2 &&
|
|
|
|
>unrelated &&
|
|
|
|
git add unrelated &&
|
|
|
|
git commit -m commit1 &&
|
|
|
|
|
|
|
|
echo >>unrelated &&
|
|
|
|
git commit -am commit2
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'rebase changes with the apply backend' '
|
|
|
|
test_when_finished "git rebase --abort || true" &&
|
|
|
|
git checkout -b apply-backend side2 &&
|
|
|
|
git rebase side1
|
|
|
|
'
|
|
|
|
|
2020-02-19 20:04:07 +03:00
|
|
|
test_expect_success 'rebase changes with the merge backend' '
|
t3433: new rebase testcase documenting a stat-dirty-like failure
A user discovered a case where they had a stack of 20 simple commits to
rebase, and the rebase would succeed in picking the first commit and
then error out with a pair of "Could not execute the todo command" and
"Your local changes to the following files would be overwritten by
merge" messages.
Their steps actually made use of the -i flag, but I switched it over to
-m to make it simpler to trigger the bug. With that flag, it bisects
back to commit 68aa495b590d (rebase: implement --merge via the
interactive machinery, 2018-12-11), but that's misleading. If you
change the -m flag to --keep-empty, then the problem persists and will
bisect back to 356ee4659bb5 (sequencer: try to commit without forking
'git commit', 2017-11-24)
After playing with the testcase for a bit, I discovered that added
--exec "sleep 1" to the command line makes the rebase succeed, making me
suspect there is some kind of discard and reloading of caches that lead
us to believe that something is stat dirty, but I didn't succeed in
digging any further than that.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-19 20:04:06 +03:00
|
|
|
test_when_finished "git rebase --abort || true" &&
|
|
|
|
git checkout -b merge-backend side2 &&
|
|
|
|
git rebase -m side1
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'rebase changes with the merge backend with a delay' '
|
|
|
|
test_when_finished "git rebase --abort || true" &&
|
|
|
|
git checkout -b merge-delay-backend side2 &&
|
|
|
|
git rebase -m --exec "sleep 1" side1
|
|
|
|
'
|
|
|
|
|
|
|
|
test_done
|