From: Jeff King <peff@peff.net>
Date: Thu, 12 Apr 2012 05:41:55 GMT
Subject: Re: Parallel refactoring and git merge nightmare
Message-ID: <20120412054155.GB27369@sigill.intra.peff.net>
In-Reply-To: <1334160803.74554.YahooMailNeo@web160603.mail.bf1.yahoo.com>

On Wed, Apr 11, 2012 at 09:13:23AM -0700, Pap Lôrinc wrote:

> I think the 
> problem arises because git doesn't track
>  moves, therefore I constantly get conflicts of type "local modified, 
> remote deleted" (or even both deleted) when in fact it was only modified
>  and moved, it could have been merged without conflicts (-> apply my 
> changes and move the file to the new location).

Git does rename detection at the time of merge, and will apply changes
to the destination file. I'm not sure why this isn't working for you.
Some theories:

  1. Git may give up on finding renames if it is very computationally
     expensive. It will print a warning in that case, but you may miss
     it in the output. You might try:

        git config merge.renamelimit 0

     to turn off the limiting.

  2. Do your files actually look like renames? Git's inexact rename
     detection looks at the file content, and correlates removed and
     added files that have a high percentage of similar content. If most
     of the file ended up changed, then the pair is not considered a
     rename.

-Peff