summaryrefslogtreecommitdiff
path: root/t/t9102-git-svn-deep-rmdir.sh
diff options
context:
space:
mode:
authorLibravatar Elijah Newren <newren@gmail.com>2020-02-19 17:04:06 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-02-19 10:13:27 -0800
commit73113c592222eac40dfdf76d9b2bbc2137d73783 (patch)
tree72d52dd149895b2109cd4f2f5179d3123a5380b7 /t/t9102-git-svn-deep-rmdir.sh
parentGit 2.25.1 (diff)
downloadtgif-73113c592222eac40dfdf76d9b2bbc2137d73783.tar.xz
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>
Diffstat (limited to 't/t9102-git-svn-deep-rmdir.sh')
0 files changed, 0 insertions, 0 deletions