Jonas Fonseca <fonseca@diku.dk> wrote:
quoted text
> 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.
...
quoted text
>  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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html