From: Shawn O. Pearce <spearce@spearce.org>
Date: Wed, 17 Oct 2007 00:55:17 GMT
Subject: Re: [PATCH] When renaming config sections delete conflicting sections
Message-ID: <20071017005517.GJ13801@spearce.org>
In-Reply-To: <20071017003418.GA11013@diku.dk>

Jonas Fonseca <fonseca@diku.dk> wrote:
> 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.
...
>  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.