Re: [PATCH] Rename git-config-set to git-repo-config

From: Junio C Hamano <junkio@cox.net>
Date: Nov 24, 2005, 11:33 UTC
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