Re: Rename edge case...

On Fri, 09 Nov 2012 04:10:31 -0500, John Szakmeister [off-list ref] 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