Re: correct git merge behavior or corner case?

From: Jeff King <peff@peff.net>
Date: Apr 21, 2009, 02:44 UTC
Message-ID: <20090421024433.GC14479@coredump.intra.peff.net>
In-Reply-To: <41354.bFoQE3daRhY=.1240222235.squirrel@webmail.hotelhot.dk>

On Mon, Apr 20, 2009 at 12:10:35PM +0200, Anders Melchiorsen wrote:

Show 31 quoted lines

> I think that I managed to recreate what he is describing.
> 
> 
> #!/bin/bash
> 
> cd $(mktemp -d repo.XXXXX)
> 
> git init
> 
> touch date
> git add date
> git commit -memptydate
> 
> git branch parallel
> 
> touch LICENSE
> git add LICENSE
> git commit -mLICENSE
> 
> git checkout parallel
> date >date
> git add date
> git commit -mdate
> 
> git checkout master
> git rm date
> git commit -mnodate
> 
> git merge parallel
> 
> cat LICENSE

So basically one branch removes a file and adds an identical file under a different name, while the other branch modifies the original file. Git detects it as a rename, and applies the change from the second branch to the newly added file instead of generating a conflict.

This is _exactly_ what git's rename detection is designed to do. Yes, it seems horribly confusing in this toy example, but that is because it is a toy example: both 'date' and 'LICENSE' are empty files. But with real files, if a source file has actual content but is deleted, there is a new filename with the identical or near-identical content, and the patch applies to the new content without conflicts, then applying it there is probably exactly what you want.

The only complaint I have in that example is that there is nothing indicating to the user that the patch was applied to a renamed version. The output I get is:

  $ git merge parallel
  Merge made by recursive.
   LICENSE |    1 +
   1 files changed, 1 insertions(+), 0 deletions(-)

Perhaps a note indicating that it applied changes for "date" to "LICENSE" would be helpful.

-Peff