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

[Avery Pennarun <apenwarr@gmail.com>]

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.

> [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