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.
Okay.
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
That makes things alot clearer, thanks.
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".
Thats great, exactly what I want to do.
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.)
Okay. The documentation, or what I have read does not really explain this
properly or concisely.
Thanks alot Steve.
Aaron
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
