On Wed, Jul 29, 2009, Junio C Hamano<gitster@xxxxxxxxx> wrote: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: >> 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. I'll send a new patch shortly that combines the two tests into one and includes the "reset --hard". > 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. You're right, using the resolve strategy does make the test pass. James -- 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