threads / patch / 14323

patchbuiltin-rerere: fix conflict markers parsing

Subject: [PATCH] builtin-rerere: fix conflict markers parsing

## tl;dr

9 messages between Jul 7, 2008 and Jul 8, 2008. Diffs are folded; open one to read it.

replies: 8people: 3as markdown or json

Olivier Marin· Jul 7, 2008, 12:42 UTC · lore
From: Olivier Marin <dkr@freesurf.fr>

When a conflicting file contains a line that begin with "=======", rerere failed to parse conflict markers. This result to a wrong preimage file and an unexpected error for the user.

This patch enforce parsing rules so that markers match in the right order and update tests to match the above fix.

Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
 This happend to me with a conflict in Documentation/git-remote.txt.
 The bug seems to have always been there but nobody noticed probably because
 before a1b32fdc3d1d05395f186bfa06e92174519dab8d parsing errors were ignored
 and (I think) it does not affect the way git rerere works.
 builtin-rerere.c  |    7 ++++---
 t/t4200-rerere.sh |   26 ++++++++++++++++++++------
 2 files changed, 24 insertions(+), 9 deletions(-)
Show changes to 2 files +24 −9

builtin-rerere.c, t/t4200-rerere.sh

diff --git a/builtin-rerere.c b/builtin-rerere.c
index 839b26e..e618862 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -112,11 +112,12 @@ static int handle_file(const char *path,
 	strbuf_init(&one, 0);
 	strbuf_init(&two,  0);
 	while (fgets(buf, sizeof(buf), f)) {
-		if (!prefixcmp(buf, "<<<<<<< "))
+		if (hunk == 0 && !prefixcmp(buf, "<<<<<<< "))
 			hunk = 1;
-		else if (!prefixcmp(buf, "======="))
+		else if (hunk == 1 && !prefixcmp(buf, "=======") &&
+			 isspace(buf[7]))
 			hunk = 2;
-		else if (!prefixcmp(buf, ">>>>>>> ")) {
+		else if (hunk == 2 && !prefixcmp(buf, ">>>>>>> ")) {
 			if (strbuf_cmp(&one, &two) > 0)
 				strbuf_swap(&one, &two);
 			hunk_no++;
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index a64727d..cf10557 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -9,6 +9,8 @@ test_description='git rerere
 . ./test-lib.sh
 
 cat > a1 << EOF
+Some title
+==========
 Whether 'tis nobler in the mind to suffer
 The slings and arrows of outrageous fortune,
 Or to take arms against a sea of troubles,
@@ -24,6 +26,8 @@ git commit -q -a -m initial
 
 git checkout -b first
 cat >> a1 << EOF
+Some title
+==========
 To die, to sleep;
 To sleep: perchance to dream: ay, there's the rub;
 For in that sleep of death what dreams may come
@@ -35,7 +39,7 @@ git commit -q -a -m first
 
 git checkout -b second master
 git show first:a1 |
-sed -e 's/To die, t/To die! T/' > a1
+sed -e 's/To die, t/To die! T/' -e 's/Some title/Some Title/' > a1
 echo "* END *" >>a1
 git commit -q -a -m second
 
@@ -55,14 +59,14 @@ test_expect_success 'conflicting merge' '
 
 sha1=$(sed -e 's/	.*//' .git/rr-cache/MERGE_RR)
 rr=.git/rr-cache/$sha1
-test_expect_success 'recorded preimage' "grep ======= $rr/preimage"
+test_expect_success 'recorded preimage' "grep ^=======$ $rr/preimage"
 
 test_expect_success 'rerere.enabled works, too' '
 	rm -rf .git/rr-cache &&
 	git config rerere.enabled true &&
 	git reset --hard &&
 	! git merge first &&
-	grep ======= $rr/preimage
+	grep ^=======$ $rr/preimage
 '
 
 test_expect_success 'no postimage or thisimage yet' \
@@ -71,7 +75,7 @@ test_expect_success 'no postimage or thisimage yet' \
 test_expect_success 'preimage has right number of lines' '
 
 	cnt=$(sed -ne "/^<<<<<<</,/^>>>>>>>/p" $rr/preimage | wc -l) &&
-	test $cnt = 9
+	test $cnt = 13
 
 '
 
@@ -80,13 +84,23 @@ git show first:a1 > a1
 cat > expect << EOF
 --- a/a1
 +++ b/a1
-@@ -6,17 +6,9 @@
+@@ -1,4 +1,4 @@
+-Some Title
++Some title
+ ==========
+ Whether 'tis nobler in the mind to suffer
+ The slings and arrows of outrageous fortune,
+@@ -8,21 +8,11 @@
  The heart-ache and the thousand natural shocks
  That flesh is heir to, 'tis a consummation
  Devoutly to be wish'd.
 -<<<<<<<
+-Some Title
+-==========
 -To die! To sleep;
 -=======
+ Some title
+ ==========
  To die, to sleep;
 ->>>>>>>
  To sleep: perchance to dream: ay, there's the rub;
@@ -124,7 +138,7 @@ test_expect_success 'another conflicting merge' '
 '
 
 git show first:a1 | sed 's/To die: t/To die! T/' > expect
-test_expect_success 'rerere kicked in' "! grep ======= a1"
+test_expect_success 'rerere kicked in' "! grep ^=======$ a1"
 
 test_expect_success 'rerere prefers first change' 'test_cmp a1 expect'
 
-- 
1.5.6.2.346.gddd7f
Johannes Schindelin· Jul 7, 2008, 13:02 UTC · re: Olivier Marin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Hi,
On Mon, 7 Jul 2008, Olivier Marin wrote:
Show 8 quoted lines
> From: Olivier Marin <dkr@freesurf.fr>
> 
> When a conflicting file contains a line that begin with "=======", rerere
> failed to parse conflict markers. This result to a wrong preimage file and
> an unexpected error for the user.
> 
> This patch enforce parsing rules so that markers match in the right order
> and update tests to match the above fix.
So what about
	<<<<<<< This hunk contains =====
	anythin
	=======
	Hello
	=======
	somethin else
	>>>>>>> problem!
If you fix it, I think you should do it properly, and analyze the index.

Ciao, Dscho

Olivier Marin· Jul 7, 2008, 13:55 UTC · re: Johannes Schindelin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Johannes Schindelin a écrit :
Show 14 quoted lines
> 
> So what about
> 
> 	<<<<<<< This hunk contains =====
> 	anythin
> 	=======
> 
> 	Hello
> 	=======
> 	somethin else
> 	>>>>>>> problem!
> 
> 
> If you fix it, I think you should do it properly, and analyze the index.

If I read the code correctly, this case is not a problem at all because what is important is the content between <<< and >>> : even if you match the wrong === marker, you will match the first one only, then parsing will success and preimage file will be OK. Also because we always match in the same order the sha1 will be the same.

Anyway, I do not know how to match the right === marker.
Olivier.
Johannes Schindelin· Jul 7, 2008, 14:06 UTC · re: Olivier Marin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Hi,
On Mon, 7 Jul 2008, Olivier Marin wrote:
Show 23 quoted lines
> Johannes Schindelin a écrit :
> > 
> > So what about
> > 
> > 	<<<<<<< This hunk contains =====
> > 	anythin
> > 	=======
> > 
> > 	Hello
> > 	=======
> > 	somethin else
> > 	>>>>>>> problem!
> > 
> > 
> > If you fix it, I think you should do it properly, and analyze the index.
> 
> If I read the code correctly, this case is not a problem at all because what
> is important is the content between <<< and >>> : even if you match the wrong
> === marker, you will match the first one only, then parsing will success and
> preimage file will be OK. Also because we always match in the same order the
> sha1 will be the same.
> 
> Anyway, I do not know how to match the right === marker.

Okay, but then the obvious question is: what do you do about "<<<<<<" lines that are not a marker?

Same remark as before: if you fix rerere, why not do it properly?

Ciao, Dscho

Olivier Marin· Jul 7, 2008, 14:44 UTC · re: Johannes Schindelin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Johannes Schindelin a écrit :
> 
> Okay, but then the obvious question is: what do you do about "<<<<<<" 
> lines that are not a marker?
The answer is the same.
> Same remark as before: if you fix rerere, why not do it properly?
If you have a better fix send a patch or at least give me some clues.
Olivier.
Johannes Schindelin· Jul 7, 2008, 15:29 UTC · re: Olivier Marin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Hi,
On Mon, 7 Jul 2008, Olivier Marin wrote:
Show 6 quoted lines
> Johannes Schindelin a écrit :
> > 
> > Okay, but then the obvious question is: what do you do about "<<<<<<" 
> > lines that are not a marker?
> 
> The answer is the same.

I think not. You say you want to do something about the ambiguity, but fact is: the conflict markers are ambiguous. They always have been, will ever be, and I do not even have to argue for it. Or do I?

> > Same remark as before: if you fix rerere, why not do it properly?
> 
> If you have a better fix send a patch or at least give me some clues.

Did I not say that the index has enough information? Or at least hint at it?

Of course, we could run with your solution. But that only fixes a corner case, right?

So a proper fix will be needed eventually anyway.

And no, I will not work on it: this is not my itch, and my time is being stolen too much already, these days.

Ciao, Dscho

Junio C Hamano· Jul 7, 2008, 17:39 UTC · re: Johannes Schindelin · lore

Re: [PATCH] builtin-rerere: fix conflict markers parsing

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> So what about
>
> 	<<<<<<< This hunk contains =====
> 	anythin
> 	=======
>
> 	Hello
> 	=======
> 	somethin else
> 	>>>>>>> problem!
>
>
> If you fix it, I think you should do it properly, and analyze the index.

I do not know offhand if analyzing the index is the right solution, but your point is very valid. You need to know which ====== is the real one to be able to properly flip sides of the conflict.

I however think detecting that we have this ambiguous hunk is easy, and punting gracefully and not re-resolving in such a case is million times better than producing random results that the users need to be worried about.

Junio C Hamano· Jul 8, 2008, 07:52 UTC · re: Junio C Hamano · lore

Re* [PATCH] builtin-rerere: fix conflict markers parsing

Junio C Hamano <gitster@pobox.com> writes:
Show 17 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So what about
>>
>> 	<<<<<<< This hunk contains =====
>> 	anythin
>> 	=======
>>
>> 	Hello
>> 	=======
>> 	somethin else
>> 	>>>>>>> problem!
>> ...
> I however think detecting that we have this ambiguous hunk is easy, and
> punting gracefully and not re-resolving in such a case is million times
> better than producing random results that the users need to be worried
> about.

I am wondering if a patch like this on top of your patch may make things even safer. The idea is the same as the earlier a1b32fd (git-rerere: detect unparsable conflicts, 2008-06-22) to fail rerere unless the markers are unambiguous.

Thanks to your isspace(buf[7]), it is slightly less likely that this safety triggers on false positives.

Thoughts?

-- >8 -- rerere: punt and do not resolve if conflict markers are ambiguous

Especially because we are introducing rerere.autoupdate configuration (which is off by default for safety) that automatically stages the resolution made by rerere, it is necessary to make sure that we do not autoresolve when there is any ambiguity.

 builtin-rerere.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)
Show changes to builtin-rerere.c +13 −4
diff --git a/builtin-rerere.c b/builtin-rerere.c
index e618862..69c3a52 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -112,12 +112,17 @@ static int handle_file(const char *path,
 	strbuf_init(&one, 0);
 	strbuf_init(&two,  0);
 	while (fgets(buf, sizeof(buf), f)) {
-		if (hunk == 0 && !prefixcmp(buf, "<<<<<<< "))
+		if (!prefixcmp(buf, "<<<<<<< ")) {
+			if (hunk)
+				goto bad;
 			hunk = 1;
-		else if (hunk == 1 && !prefixcmp(buf, "=======") &&
-			 isspace(buf[7]))
+		} else if (!prefixcmp(buf, "=======") && isspace(buf[7])) {
+			if (hunk != 1)
+				goto bad;
 			hunk = 2;
-		else if (hunk == 2 && !prefixcmp(buf, ">>>>>>> ")) {
+		} else if (!prefixcmp(buf, ">>>>>>> ")) {
+			if (hunk != 2)
+				goto bad;
 			if (strbuf_cmp(&one, &two) > 0)
 				strbuf_swap(&one, &two);
 			hunk_no++;
@@ -143,6 +148,10 @@ static int handle_file(const char *path,
 			strbuf_addstr(&two, buf);
 		else if (out)
 			fputs(buf, out);
+		continue;
+	bad:
+		hunk = 99; /* force error exit */
+		break;
 	}
 	strbuf_release(&one);
 	strbuf_release(&two);
Olivier Marin· Jul 8, 2008, 10:42 UTC · re: Junio C Hamano · lore

Re: Re* [PATCH] builtin-rerere: fix conflict markers parsing

Junio C Hamano a écrit :
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> I am wondering if a patch like this on top of your patch may make things
> even safer.  The idea is the same as the earlier a1b32fd (git-rerere:
> detect unparsable conflicts, 2008-06-22) to fail rerere unless the markers
> are unambiguous.
> 
> Thanks to your isspace(buf[7]), it is slightly less likely that this
> safety triggers on false positives.
> 
> Thoughts?

My main concern was the error message that most users will not understand after a "git rebase --continue", for example. So, I tried to remove it and let things work as before because rerere seems to work even with ambiguous cases.

But I think your patch is the right thing to do: safe is better.
Olivier.

← back to recent threads