Re: retrospective move

From: Santi Béjar <santi@agolina.net>
Date: Feb 4, 2009, 10:31 UTC
Message-ID: <adf1fd3d0902040231h2fb6f199oee143e36a7501a2a@mail.gmail.com>
In-Reply-To: <200902041017.47564.trast@student.ethz.ch>

2009/2/4 Thomas Rast <trast@student.ethz.ch>:

Show 14 quoted lines

> jemmyw wrote:
>>
>> Hi. Awhile ago I copied some files in my local repo then commited. In another
>> commit I deleted the original files, so essentially I did a mv that git
>> doesn't know about. Now I'm trying to merge from another branch where
>> changes have happened to the files in their original locations, and it's
>> making the merge somewhat difficult. Is there a way to ease this?
>
> Git never "knows" about a move, it only detects them after the fact.
> A corollary of this is that 'git mv a b' is more or less the same as
> 'cp a b; git rm a; git add b'.
>
> Now since you have a copy followed by a removal in two separate
> commits, the merge logic won't treat this as a rename.

I don't think it holds. Git only sees the endpoints and the bases, it does not matter if the "move" was actually two commits. Maybe they have changed dramatically and git is not able to detect the rename (or the files are small). Another possible cause could be that you have a lot of renames (see config merge.renamelimit).

You could see if git detects the rename diffing differents commits:

$ git diff --raw -M commit1 commit2

if it does not detect you could use other limits as:

$ git diff --raw -M50 commit1 commit2

while commit1 and 2 are the endpoints or the merge base.

It could hep if you could provide a minimal test case, or at least the commands and output you get.

HTH, Santi