Re: git-mv redux: there must be something else going on

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 3, 2010, 18:48 UTC
Message-ID: <32541b131002031048i26d166d9w3567a60515235c34@mail.gmail.com>
In-Reply-To: <ron1-32BD5F.10255403022010@news.gmane.org>

On Wed, Feb 3, 2010 at 1:25 PM, Ron Garret <ron1@flownet.com> wrote:

> So something in my understanding of how git works must be wrong.  Git
> must be keeping a separate record of file renames somewhere.  But where?

It doesn't.  Your experiment is wrong.

Show 11 quoted lines

> [ron@mickey:~/devel/gittest]$ cat>file2
> 6
> 7
> 8
> 9
> 10
> [ron@mickey:~/devel/gittest]$ git mv file2 file3
> [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers'
> [master ae3f6d4] letters->numbers
>  1 files changed, 0 insertions(+), 0 deletions(-)
>  rename file2 => file3 (100%)

Whoops. You didn't 'git add file2' (before the mv) or 'git add file3' (after the mv), or use commit -a, so what you've committed is the *old* content of file2 under the name file3. The *new* content of file2 is still uncommitted in your work tree under the name file3. This is why git can detect the move. (The 100% is a good clue: it means the old and new files are 100% identical.)

Artificial tests like this are useless anyway. If you renamed file2 to file3 *and* changed all the contents, did you *really* rename it? If so, who cares? What good does it do you to know this? If someone else tries to patch the old file2 and you merge it into a (totally different) file3 vs a (now missing) file2, how is that any better?

On the other hand, if one guy moves file2 to file3 and changes a few lines, you want the other guy's patch to go into file3, whether the first guy used 'git mv' or add+rm or anything else.

As long as only a few lines changed, git does the right thing. If most/all of the lines have changed, then there is no right thing, because you'll get a nasty merge conflict either way.

Have fun,

Avery