Git doesn't care. You can do renames by hand, or with "git mv", you can do
them as a delete/create pair, you can use "git-apply" with a rename patch,
and you can do them by re-typing in all of the file contents from scratch.
Regardless of how the rename is done, git will represent the data the
exact same way: the state of the tree before and after.
The rename-patches are a lot denser and a lot more readable for humans (ie
you can actually see what *happens*, unlike a traditional stupid unified
diff), and I was hoping that eventually somebody in the GNU patch
community would see how wonderful the extended patch information is, but
when I tried to write a patch to "patch" to do it, I almost dug out my
eyes with spoons from looking at the source code, so I haven't actually
helped it happen.
So you can ask for patches in traditional format (*most* git command lines
will default to that anyway, and only give a copy-patch with -C or -M on
the command line), or people could realize that "git-apply" actually works
even on non-git source code, and just stop using that abomination that is
"patch" with all of it's totally wrong and unsafe defaults (*).
But whatever works. I'm currently skipping the patches since they didn't
seem like 2.6.24 fodder anyway.
Linus
(*) Let me count the ways: applying patches partially when it fails
half-way through a series. Defaulting to totally randomly guessing the
path-name skip depth when not explicitly given a -pX option. Defaulting to
"--fuzz=2" which is almost guaranteed to apply a patch even when it makes
no sense what-so-ever. Yes, git-apply has stricter rules, but they are
stricter for damn good reasons. For people who want the insane unsafe GNU
patch defaults, they just have to specifically ask for unsafe modes..
-
