From: Jonas Fonseca Date: Wed, 17 Oct 2007 10:37:26 GMT Subject: Re: [PATCH] When renaming config sections delete conflicting sections Message-ID: <20071017103726.GA23417@diku.dk> In-Reply-To: <20071017005517.GJ13801@spearce.org> Shawn O. Pearce wrote Tue, Oct 16, 2007: > Jonas Fonseca 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. True, but to me the meaning of -M is "I know what I am doing". > 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. You never know, and sure if there is an option to gracefully avoid lossing this information that is the right approach, but I don't see how this can be done in this situation. Besides currently only branch.$name.mergoptions will be lost, hardly a problem. > Its really hard to second guess the user's intent here. I think > its too broad to whack an entire section when renaming. [...] > > 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. Because it makes sense in this situation and erroring out is a good choice, but we are running out of git-branch options based on the letter 'm'. And to me, -m is the default for renaming branches, and -M is a shortcut for doing a lot of other stuff with well-defined implications. Perhaps we can enable only this "lossy behavior" only for git-branch by adding an extra argument to git_config_rename_section? Then we can later add a new option to git-config along the lines of --overwrite-section. -- Jonas Fonseca