Re: renaming question

Florian Weimer wrote:

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