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

[Tom Lord]

    > From: Jan Hudec <address@hidden>

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

(a) There's some ambiguity about the choice of ANCESTOR (the primary
reason these commands don't make one).

(b) It isn't at all obvious, even given a fixed choice of ANCESTOR,
that diff3 will do a better job.

So: I'd rather see separate command invocations for the `patch'
vs. `diff3' functionality and let users pick the one they want.



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

I wish I was less busy moving right now but, since I'm not:  would
anyone like to spend some time on citeseer and then reading papers to
review and summarize the diff3 algorithm and try to explain concisely
but with precision what the issue is?


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

As discussed in another recent thread with abently, I think there's a
very, very natural fit just by parameterizing how `star-merge' picks
ANCESTOR.  In other words, this should be easy to build-in to tla ---
the only odd thing being that we might want to provide the
functionality under some name other than the (then misnomer)
`star-merge'.

-t