On Fri, 09 Nov 2012 04:10:31 -0500, John Szakmeister <john@xxxxxxxxxxxxxxx> wrote: > I've been browsing StackOverflow answering git-related questions, and > ran across this one: > <http://stackoverflow.com/questions/13300675/git-merge-rename-conflict> > > It's a bit of an interesting situation. The user did a couple of > renames in a branch: > foo.txt => fooOld.txt > fooNew.txt => foo.txt > > Meanwhile, master had an update to fooNew.txt. When the user tried to > merge master to the branch, it gave a merge conflict saying fooNew.txt > was deleted, but master tried to update it. > > I was a bit surprised that git didn't follow the rename here, though I > do understand why: git only sees it as a rename if the source > disappears completely. So I played locally with a few ideas, and was > surprised to find out that even breaking up the two renames into two > separate commits git still didn't follow it. > > I'm just curious--I don't run into this often myself--but is there a > good strategy for dealing with this that avoids the conflict? When merging two branches, git only looks at the tips. It doesn't inspect their histories to see how the files were moved around. So i doesn't matter whether you rename the files in a single commit or multiple commits. The resulting tree is always the same. tom -- 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