Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: >> +test_expect_failure 'checkout should not delete a/b-2/c/d' ' >> + git checkout -b temp HEAD^ && >> + test -f a/b-2/c/d >> +' >> + >> +test_expect_failure 'merge should not delete a/b-2/c/d' ' >> + echo x > a/x && >> + git add a/x && >> + git commit -m x && >> + git merge master && >> + test -f a/b-2/c/d >> +' >> + >> +test_done > > Isn't the failure of the second test caused by that of the first one? > a/b-2/c/d is gone from the worktree, and master does not touch it, so > the merge leaves the worktree version (non-existent) as is. To avoid that impression the second test should probably have been written to start from a clean slate, using "reset --hard" or something. Kjetil's patch actually fixes the first one, but the second one will still show breakage. I wonder if the breakage is in recursive merge or in the generic read-tree three-way merge code. I highly suspect that using "git merge -s resolve" would make the test pass. Historically recursive merge is known to be careless in many corner cases. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html