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