gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: <<< conflict markers


From: Stefan Monnier
Subject: Re: [Gnu-arch-users] Re: <<< conflict markers
Date: 15 Apr 2004 11:35:58 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>>> I want changeset-application-with-conflicts to be cleanly composable
>>> and somewhat decomposable.
>> If we only consider diff3 markers, this works fine in 99% of the cases.
>> The only cases where it might result in ambiguous results is if you merge
>> two trees which both have conflict markers at the same place in a file.

> If a label were attached to conflict markers, they'd be unambiguous for that
> case, too.

> <<<<< 1
> la la
> <<<<< 2
> fa fa
> ===== 2
> >>>>> 2
> tra-la-la
> ===== 1
> >>>>> 1

Note that the above is "unambiguous" even without labels if you assume
proper nesting (which is the only sane assumption).

I actually found it pretty difficult to construct a realistic case where
conflicts do not properly nest.  How about a nasty one:

Ancestor:
     foo

File1:
     <<<<<<< 1
     foo
     ======= 1
     bar
     >>>>>>> 1

File2:
     <<<<<<< 2
     foo
     ======= 2
     bar
     >>>>>>> 2

Result:
     <<<<<<< 3
     <<<<<<< 1
     ======= 3
     <<<<<<< 2
     >>>>>>> 3
     foo
     <<<<<<< 4
     ======= 1
     bar
     >>>>>>> 1
     ======= 4
     ======= 2
     bar
     >>>>>>> 2
     >>>>>>> 4

A similar but simpler one (with no merging of conflicts: only accumulation):

Ancestor:
     foo

File1:
     toto
     foo

File2:
     <<<<<<< 2
     foo
     ======= 2
     bar
     >>>>>>> 2

Result:
     <<<<<<< 3
     toto
     ======= 3
     <<<<<<< 2
     >>>>>>> 3
     foo
     ======= 2
     bar
     >>>>>>> 2

Note that in the format generated by `diff3' (and documented in the diff3
manual) there is never any label attached, so if we add such labels it
would result in generating non-standard markers.

> And that doesn't solve to problem that .rej conflicts refer to context that
> may not be present anywhere in TREE or ANCESTOR.

Yes, I was only pointing out that the `star-merge --three-way' approach
usually handles accumulated conflicts acceptably.  Not only it's not 100%
correct, but it indeed doesn't answer the question of what to do with .rej
conflicts.
Thing is I haven't had .rej conflicts since I discovered the --three-way
option of star-merge ;-)

As for what to do with accumulated .rej conflicts: they should probably be
simply concatenated.

> One thing I like about .rej conflicts is that it's easy to detect them in
> scripts.  But I really would prefer unified diffs.

It's easy to convert them.  I've customized my Emacs to automatically
convert to unified format when I open a .rej file.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]