[PATCH] builtin-rerere: fix conflict markers parsing

[PATCH] builtin-rerere: fix conflict markers parsing

[Olivier Marin]

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(-)

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

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

[Johannes Schindelin]

Hi,

On Mon, 7 Jul 2008, Olivier Marin wrote:

> 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

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

[Olivier Marin]

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.

Olivier.

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 916 bytes --]

Hi,

On Mon, 7 Jul 2008, Olivier Marin wrote:

> 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

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

[Olivier Marin]

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.

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

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 920 bytes --]

Hi,

On Mon, 7 Jul 2008, Olivier Marin wrote:

> 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

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> 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(-)

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);

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

[Olivier Marin]

Junio C Hamano a écrit :
> 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.