When renaming config sections delete conflicting sections

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.

---
 config.c               |    9 ++++++++-
 t/t1300-repo-config.sh |   17 +++++++++++++++++
 2 files changed, 25 insertions(+), 1 deletions(-)

This command sequence was causing problems for me:

git checkout -b test madcoder/next
git checkout -b test2 spearce/next
git branch -M test

On top of spearce/next ...

index dc3148d..578849a 100644
@@ -1013,6 +1013,14 @@ int git_config_rename_section(const char *old_name, const char *new_name)
 			; /* do nothing */
 		if (buf[i] == '[') {
 			/* it's a section */
+			remove = 0;
+			if (new_name != NULL
+			    && section_name_match (&buf[i+1], new_name)) {
+				/* Remove any existing occurences of the
+				 * new section. */
+				remove = 1;
+				continue;
+			}
 			if (section_name_match (&buf[i+1], old_name)) {
 				ret++;
 				if (new_name == NULL) {

@@ -1026,7 +1034,6 @@ int git_config_rename_section(const char *old_name, const char *new_name)
 				}
 				continue;
 			}
-			remove = 0;
 		}
 		if (remove)
 			continue;

index 1d2bf2c..63b969e 100755
@@ -419,6 +419,23 @@ EOF
 test_expect_success "section was removed properly" \
 	"git diff -u expect .git/config"
 
+cat > .git/config << EOF
+[branch "new-name"]
+	x = 1
+[branch "old-name"]
+	y = 1
+EOF
+
+test_expect_success "rename and remove old section" \
+	'git config --rename-section branch.old-name branch.new-name'
+
+cat > expect << EOF
+[branch "new-name"]
+	y = 1
+EOF
+
+test_expect_success "rename and remove succeeded" "git diff expect .git/config"
+
 rm .git/config
 
 cat > expect << EOF

1.5.3.4.1206.g5f96-dirty

-- 
Jonas Fonseca

...

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.

Shawn O. Pearce <[email protected]> wrote Tue, Oct 16, 2007:

True, but to me the meaning of -M is "I know what I am doing".

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.

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