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

From: Jonas Fonseca <fonseca@diku.dk>
Date: Oct 17, 2007, 10:37 UTC
Message-ID: <20071017103726.GA23417@diku.dk>
In-Reply-To: <20071017005517.GJ13801@spearce.org>

Shawn O. Pearce <spearce@spearce.org> wrote Tue, Oct 16, 2007:

Show 15 quoted lines

> 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".

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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