From: Junio C Hamano <junkio@cox.net>
Date: Thu, 24 Nov 2005 11:33:30 GMT
Subject: Re: [PATCH] Rename git-config-set to git-repo-config
Message-ID: <7v8xveth4l.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0511241127020.12985@wbgn013.biozentrum.uni-wuerzburg.de>

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