Re: Parallel refactoring and git merge nightmare

From: Jeff King <peff@peff.net>
Date: Apr 12, 2012, 05:41 UTC
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:

Show 6 quoted lines

> 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