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

[Jan Hudec]

On Wed, Apr 14, 2004 at 11:28:20 -0700, Tom Lord wrote:
> 
>     > From: Jani Monoses <address@hidden>
> 
>     > star-merge -t generates diff3 style merges instead of making conflict
>     > files and rejects.
> 
>     > It seems to me such a feature would be useful for other patch applying
>     > commands as well such as redo replay etc. Comments? This is not a
>     > feature request because again I might miss some deep reason why only
>     > star-merge has/needs this.
> 
> diff3-style conflict markers really only make sense when the program
> creating them has three files on hand: ANCESTOR, MINE, and YOURS.
> 
> `replay', `redo', etc. all work (currently) on the basis of diffs, not
> 3-way merges.   They have only one file on hand (MINE) plus a set of
> diffs from ANCESTOR to YOURS.   They don't use that style of conflict
> marker for the same reason that `patch (1)' doesn't --- patch can
> _guess_ where the conflicting hunk goes, but it doesn't know for sure,
> and doesn't know what lines in MINE it conflicts with.

These commands don't have "ancestor" handy, but can reconstruct it. For
these commands, it makes sense to use normal patch and _if_ it fails,
redo the operation using diff3 and reconstructed ancestor.

> There are two ways to get the kind of feature you want (and that I'd
> like, too):
> 
> 1) modify patch to record conflicts internally to a file.   They won't
>    be the usual kind of <<</---/>>> markers, but there's no reason
>    that the contents of a .rej file can't be stored in the patched
>    file instead of separately.

Wiggle does it. And it does look like diff3 markers. Unfortunately,
without the full text of "ancestor", it's impossible to get right.

> 2) create new commands that are similar to replay, redo, etc. but
>    which do, in fact, do 3-way merges.   It's an open question (a
>    small "practical research" problem how such varients should work
>    and whether or not they'll prove useful.
> 
>    I _think_ they'll be pretty useful and should work in an obvious
>    way.  For example, if I'm going to 3-way replay your
>    patch-N...patch-X into my tree, then, use your patch-(N-1) as
>    ANCESTOR.
> 
>    It's not quite "low-hanging fruit" but you shouldn't need more than
>    a step ladder  (i.e., a couple of days work).

I actualy had this kind of functionality in a shell wrapper! Not at all
hard. For star-merge, having the functionality in tla directly is simple
(because it has the files built already). But for replay, the efficiency
is the same if you do post-mortem resolution.

I could dig it out and port it to aba, if I get some time.
(It is in address@hidden/arch-tools--main--1.0 if anyone is
interested to look at it).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature