[PATCH] When renaming config sections delete conflicting sections

[PATCH] When renaming config sections delete conflicting sections

[Jonas Fonseca]

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.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
 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 ...

diff --git a/config.c b/config.c
index dc3148d..578849a 100644
--- a/config.c
+++ b/config.c
@@ -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;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1d2bf2c..63b969e 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -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

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

[Shawn O. Pearce]

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.

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.

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

[Jonas Fonseca]

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