Re: renaming question

[Steven Grimm <koreth@midwinter.com>]

Florian Weimer wrote:
> Or, for more control about what gets put into patch, git-diff -M.
> (As I wrote, most of the relevant commands accept an -M switch.)
>   

The key point, and where the original writer is probably confused, is 
that in git, renames are inferred from information in the repository. 
You do not ever need to explicitly tell git about a rename. There is a 
"git mv" command which is simply a convenience command; it is equivalent to

mv a b
git add b
git rm a

When you query history with the -M flag or do merges, git will notice 
that the contents of the new file "b" are very similar to the old file 
"a" and will treat it as a rename. (The contents don't have to match 
exactly; they just have to be substantially similar.)

This is not a perfect system -- there are known cases where it fails -- 
but it has major advantages too. For example, you can unpack a 
third-party tarfile into a git repository, commit it, then unpack the 
next version's tarfile and commit that. Since you are using tar, nothing 
will have told git about files that the upstream people renamed in 
between versions, but git will detect them after the fact just as if 
you'd done "git mv".

Not only that, git can detect movement of content *within* files. Try 
moving some code from one file to another and running "git blame -M -C 
-C" on the target file; you will see git tell you that the content 
originally came from the first file. Pretty sweet. (It's not the default 
since it makes "git blame" slower.)

-Steve