Thanks for the patch. I unfortunately was doing the same,
because I wanted to get the repo-format-validation stuff into a
presentable shape, and I thought this would interfere with it
and wanted to do it first (fortunately it didn't). They are
both in the proposed updates branch. At a quick glance, I think
your patch is identical to what I did (there aren't that many
different ways to rename a command after all).
Sorry, git-mv did not work on my system. I can now confirm that
there is *at least* one perl 5.6 version out there which does not
like lists in open statements at all. Grmpf.
Yeah, perl5.8delta says that is 5.8 feature. As discussed on
the list with Merlyn, we have a fair amount of backporting, I
suspect. At least we should work on 5.6, if not 5.5.
I do not use git-mv myself. It does not work in subdirectories,
and typing Documentation/ twice to move just one file is a
chore, so I tend to just 'R' (rename) the file, move to the
renamed file, and '!' (run shell command on the specified path)
with 'git-add', all within a single Emacs dired buffer.
Further grpmf: Is it intended behaviour that git-diff *detects*
renames, while git-format-patch *doesn't*?
I do not want to force all the kernel subsystem maintainers to
use git (namely, git-apply) to process e-mails, so format-patch
should not default to git specific renaming patches.
An option to git-format-patch _might_ make sense someday. Maybe
after the world domination ;-).
Oh, wait. It already can produce renaming patches, just does
not do it by default.
Junio "again I forgot what I implemented before;
sheesh I even used it myself to feed some patches
to Linus" Hamano