On Tue, Apr 05, 2011 at 06:18:28PM -0400, Jeff King wrote: > > I _think_ the reason we originally insisted on clean working tree was that > > while merge-resolve has always had an acurate check, merge-recursive's > > check was not very good, especially when renames are involved. So > > probably this part of your comment ... > > > > > I'm not sure if the check was perhaps even required when git-stash was > > > written, and has simply since become useless as merge-recursive became > > > more careful. > > > > ... may need to be used to rewrite bullet 2. above. > > That makes sense to me. I'd be a lot more comfortable if I could find > the actual place where merge-recursive got more accurate. I'll see if > it's simple to bisect. Hmm, no such luck. In v1.5.0, before stash even existed, "git merge" will properly fail on this case (though the error message isn't as pretty): -- >8 -- #!/bin/sh rm -rf repo mkdir repo && cd repo && git init-db && echo base >file && git add file && git commit -m base && echo master >>file && git commit -a -m master && git checkout -b other HEAD^ echo other >>file && git commit -a -m other && echo more >>file && git merge master -- 8< -- which leads me to believe there is a more complex case that merge-recursive wasn't handling at the time, and which may or may not be handled better today. What that case would be, I have no clue. -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