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