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

[Jonas Fonseca <fonseca@diku.dk>]

Shawn O. Pearce <spearce@spearce.org> wrote Tue, Oct 16, 2007:
> 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.

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