On Mon, Sep 12, 2011 at 08:55:12PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I'm not sure if we were ever using merge-recursive like that. Especially > > with Elijah's latest patches to handle worktree dirtiness better, I > > wouldn't be surprised if it has issues. > > I am parsing the above as "seeing the need for such an extensive fix-up, > it is not surprising if the base code is broken", and I have to agree. Well, both. I assume that merge-recursive now cares more than ever about what is in the working tree, because I seem to recall Elijah handling some cases with untracked files. And also, his patches have given me no faith whatsoever in the quality of the underlying code. :) > In principle, "git merge" should be usable in an empty working tree in the > sense that with correctly populated index the absense of the working tree > file is _meant_ to be treated the same as having the file unchanged from > the index and the HEAD version, but I suspect that "merge-recursive" is > pretty much broken with that regard. > > I have much more faith in "git merge -s resolve" performing correctly. Agreed, though I haven't tried it. -Peff -- 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