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

[Tom Lord]

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

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.

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

-t