Re: [BUG] git config gets confused

Subsystems: the rest

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [BUG] git config gets confused

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:10

Frank Lichtenheld [off-list ref] writes:
While working on test cases for git-cvsserver, especially the config
file handling I noticed the following bug in git-config:

$ git-config gitcvs.enabled true
$ git-config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite
$ git-config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite

expected result:

[gitcvs]
        enabled = true
        dbname = %Ggitcvs2.%a.%m.sqlite
[gitcvs "ext"]
        dbname = %Ggitcvs1.%a.%m.sqlite

actual result:

[gitcvs]
        enabled = true
[gitcvs "ext"]
        dbname = %Ggitcvs1.%a.%m.sqlite
        dbname = %Ggitcvs2.%a.%m.sqlite
Oh, boy.

Why am I not surprised by another bug in config writer?

Dscho, does this look good?

-- >8 --
git-config: do not forget "a.b.var" already ends "a.var" section.

Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way.  Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.

Signed-off-by: Junio C Hamano <redacted>

---
 config.c |   26 ++++++++++++++++++++++----
 1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index 70d1055..70e6e7e 100644
--- a/config.c
+++ b/config.c
@@ -451,6 +451,9 @@ static int matches(const char* key, const char* value)
 
 static int store_aux(const char* key, const char* value)
 {
+	const char *ep;
+	size_t section_len;
+
 	switch (store.state) {
 	case KEY_SEEN:
 		if (matches(key, value)) {
@@ -468,12 +471,27 @@ static int store_aux(const char* key, const char* value)
 		}
 		break;
 	case SECTION_SEEN:
-		if (strncmp(key, store.key, store.baselen+1)) {
+		/*
+		 * What we are looking for is in store.key (both
+		 * section and var), and its section part is baselen
+		 * long.  We found key (again, both section and var).
+		 * We would want to know if this key is in the same
+		 * section as what we are looking for.
+		 */
+		ep = strrchr(key, '.');
+		section_len = ep - key;
+
+		if ((section_len != store.baselen) ||
+		    memcmp(key, store.key, section_len+1)) {
 			store.state = SECTION_END_SEEN;
 			break;
-		} else
-			/* do not increment matches: this is no match */
-			store.offset[store.seen] = ftell(config_file);
+		}
+
+		/*
+		 * Do not increment matches: this is no match, but we
+		 * just made sure we are in the desired section.
+		 */
+		store.offset[store.seen] = ftell(config_file);
 		/* fallthru */
 	case SECTION_END_SEEN:
 	case START:

[PATCH] git-config: test for 'do not forget "a.b.var" already ends "a.var" section'.

From: Steffen Prohaska <hidden>
Date: 2016-06-15 22:43:10

Added test for mentioned bugfix.

Signed-off-by: Steffen Prohaska <redacted>
---
 t/t1300-repo-config.sh |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 78c2e08..91d572c 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -407,6 +407,22 @@ EOF
 test_expect_success "section was removed properly" \
 	"git diff -u expect .git/config"
 
+rm .git/config
+
+git-config gitcvs.enabled true
+git-config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite
+git-config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite
+
+cat > expect << EOF
+[gitcvs]
+	enabled = true
+	dbname = %Ggitcvs2.%a.%m.sqlite
+[gitcvs "ext"]
+	dbname = %Ggitcvs1.%a.%m.sqlite
+EOF
+
+test_expect_success 'section ending' 'cmp .git/config expect'
+
 test_expect_success numbers '
 
 	git-config kilo.gram 1k &&
-- 
1.5.1.2

Re: [BUG] git config gets confused

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:10

Hi,

On Sat, 12 May 2007, Junio C Hamano wrote:
Oh, boy.

Why am I not surprised by another bug in config writer?

Dscho, does this look good?
Yes, it does. This part of the config writer dates slightly prior to our 
allowing hierarchical section names, which explains this bug, methinks.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help