Re: [PATCH] When renaming config sections delete conflicting sections

From: Shawn O. Pearce <spearce@spearce.org>
Date: Oct 17, 2007, 00:55 UTC
Message-ID: <20071017005517.GJ13801@spearce.org>
In-Reply-To: <20071017003418.GA11013@diku.dk>

Jonas Fonseca <fonseca@diku.dk> wrote:

Show 5 quoted lines

> The old behavior of keeping config sections matching the new name caused
> problems leading to warnings being emitted by git-remote when renaming
> branches where information about tracked remote branches differed. To
> fix this any config sections that will conflict with the new name are
> removed from the config file. Update test to check for this.

...

Show 5 quoted lines

>  This command sequence was causing problems for me:
> 
> 	git checkout -b test madcoder/next
> 	git checkout -b test2 spearce/next
> 	git branch -M test

Ouch. But this may cause the user to lose what they might consider important settings relative to the old section named branch.test.

I think in the case you mention above where you are doing a `branch -M` the user really does want the basic branch properties to be forced over (branch.$name.remote, branch.$name.merge) but they probably do not want other branch properties to be removed or deleted. Or maybe they do.

Its really hard to second guess the user's intent here. I think its too broad to whack an entire section when renaming. For example today lets say I do:

	cat >.git/config <<EOF
	[remote "many"]
		url = blah
		fetch = refs/heads/master
		fetch = refs/heads/next
	EOF

	$ git config remote.many.fetch refs/heads/pu
	Warning: remote.many.fetch has multiple values

	cat .git/config
	[remote "many"]
		url = blah
		fetch = refs/heads/master
		fetch = refs/heads/next

So we don't blindly replace multi-valued keys just because the user asked us to. I don't really see a section as being that much different to warrant a potentially lossy behavior by default.

-- 
Shawn.