Re: [PATCH v3 10/11] rerere: teach rerere to handle nested conflicts

[Thomas Gummerer <t.gummerer@gmail.com>]

On 07/30, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
> 
> > Currently rerere can't handle nested conflicts and will error out when
> > it encounters such conflicts.  Do that by recursively calling the
> > 'handle_conflict' function to normalize the conflict.
> >
> > The conflict ID calculation here deserves some explanation:
> >
> > As we are using the same handle_conflict function, the nested conflict
> > is normalized the same way as for non-nested conflicts, which means
> > the ancestor in the diff3 case is stripped out, and the parts of the
> > conflict are ordered alphabetically.
> >
> > The conflict ID is however is only calculated in the top level
> > handle_conflict call, so it will include the markers that 'rerere'
> > adds to the output.  e.g. say there's the following conflict:
> >
> >     <<<<<<< HEAD
> >     1
> >     =======
> >     <<<<<<< HEAD
> >     3
> >     =======
> >     2
> >     >>>>>>> branch-2
> >     >>>>>>> branch-3~
> 
> Hmph, I vaguely recall that I made inner merges to use the conflict
> markers automatically lengthened (by two, if I recall correctly)
> than its immediate outer merge.  Wouldn't the above look more like
> 
>      <<<<<<< HEAD
>      1
>      =======
>      <<<<<<<<< HEAD
>      3
>      =========
>      2
>      >>>>>>>>> branch-2
>      >>>>>>> branch-3~
>     
> Perhaps I am not recalling it correctly.

The only way I could reproduce this is by not resolving a conflict
(just leaving the conflict markers in place, but running 'git add
conflicted'), and then merging something else, which produces another
conflict, where one of the sides was the one with conflict markers
already in the file, same as what I did in the test.

So in that case, the conflict markers of the already existing conflict
would just be treated as normal text during the merge I believe, and
thus the new conflict markers would be the same length.

The usage of git is really a bit wrong here, so I don't know if it's
actually worth helping the users at this point.  But trying to
understand how rerere exactly works, I had this written up already, so
I thought I would include it in this series anyway in case it helps
somebody :)

> > it would be recorde as follows in the preimage:
> >
> >     <<<<<<<
> >     1
> >     =======
> >     <<<<<<<
> >     2
> >     =======
> >     3
> >     >>>>>>>
> >     >>>>>>>
> >
> > and the conflict ID would be calculated as
> >
> >     sha1(1<NUL><<<<<<<
> >     2
> >     =======
> >     3
> >     >>>>>>><NUL>)
> >
> > Stripping out vs. leaving the conflict markers in place in the inner
> > conflict should have no practical impact, but it simplifies the
> > implementation.
> >
> > Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
> > ---
> >  Documentation/technical/rerere.txt | 42 ++++++++++++++++++++++++++++++
> >  rerere.c                           | 10 +++++--
> >  t/t4200-rerere.sh                  | 37 ++++++++++++++++++++++++++
> >  3 files changed, 87 insertions(+), 2 deletions(-)
> >
> > [..snip..]
> > 
> > diff --git a/rerere.c b/rerere.c
> > index a35b88916c..f78bef80b1 100644
> > --- a/rerere.c
> > +++ b/rerere.c
> > @@ -365,12 +365,18 @@ static int handle_conflict(struct strbuf *out, struct rerere_io *io,
> >  		RR_SIDE_1 = 0, RR_SIDE_2, RR_ORIGINAL
> >  	} hunk = RR_SIDE_1;
> >  	struct strbuf one = STRBUF_INIT, two = STRBUF_INIT;
> > -	struct strbuf buf = STRBUF_INIT;
> > +	struct strbuf buf = STRBUF_INIT, conflict = STRBUF_INIT;
> >  	int has_conflicts = -1;
> >  
> >  	while (!io->getline(&buf, io)) {
> >  		if (is_cmarker(buf.buf, '<', marker_size)) {
> > -			break;
> > +			if (handle_conflict(&conflict, io, marker_size, NULL) < 0)
> > +				break;
> > +			if (hunk == RR_SIDE_1)
> > +				strbuf_addbuf(&one, &conflict);
> > +			else
> > +				strbuf_addbuf(&two, &conflict);
> 
> Hmph, do we ever see the inner conflict block while we are skipping
> and ignoring the common ancestor version, or it is impossible that
> we see '<' only while processing either our or their side?

As mentioned above, I haven't been able to reproduce creating an inner
conflict block outside of the case mentioned above, where the user
committed conflict markers, and then did another merge.

I don't think it can appear outside of that case in "normal"
operation.

> > +			strbuf_release(&conflict);
> >  		} else if (is_cmarker(buf.buf, '|', marker_size)) {
> >  			if (hunk != RR_SIDE_1)
> >  				break;
> > diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
> > index 34f0518a5e..d63fe2b33b 100755
> > --- a/t/t4200-rerere.sh
> > +++ b/t/t4200-rerere.sh
> > @@ -602,4 +602,41 @@ test_expect_success 'rerere with unexpected conflict markers does not crash' '
> >  	git rerere clear
> >  '
> >  
> > +test_expect_success 'rerere with inner conflict markers' '
> > +	git reset --hard &&
> > +
> > +	git checkout -b A master &&
> > +	echo "bar" >test &&
> > +	git add test &&
> > +	git commit -q -m two &&
> > +	echo "baz" >test &&
> > +	git add test &&
> > +	git commit -q -m three &&
> > +
> > +	git reset --hard &&
> > +	git checkout -b B master &&
> > +	echo "foo" >test &&
> > +	git add test &&
> > +	git commit -q -a -m one &&
> > +
> > +	test_must_fail git merge A~ &&
> > +	git add test &&
> > +	git commit -q -m "will solve conflicts later" &&
> > +	test_must_fail git merge A &&
> > +
> > +	echo "resolved" >test &&
> > +	git add test &&
> > +	git commit -q -m "solved conflict" &&
> > +
> > +	echo "resolved" >expect &&
> > +
> > +	git reset --hard HEAD~~ &&
> > +	test_must_fail git merge A~ &&
> > +	git add test &&
> > +	git commit -q -m "will solve conflicts later" &&
> > +	test_must_fail git merge A &&
> > +	cat test >actual &&
> > +	test_cmp expect actual
> > +'
> > +
> >  test_done