threads / patch / 10333

patchWhen renaming config sections delete conflicting sections

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

## tl;dr

3 messages between Oct 17, 2007 and Oct 17, 2007. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Jonas Fonseca· Oct 17, 2007, 00:34 UTC · lore

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

Show changes to 2 files +25 −1

config.c, t/t1300-repo-config.sh

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

Shawn O. Pearce· Oct 17, 2007, 00:55 UTC · re: Jonas Fonseca · lore

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

Jonas Fonseca <fonseca@diku.dk> wrote:

Show 5 quoted lines

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

...

Show 5 quoted lines

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

Jonas Fonseca· Oct 17, 2007, 10:37 UTC · re: Shawn O. Pearce · lore

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

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