Re: Rename edge case...

[Tomas Carnecky <tomas.carnecky@gmail.com>]

On Fri, 09 Nov 2012 04:10:31 -0500, John Szakmeister <john@szakmeister.net> 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