[Monotone-devel] Re: merging interface

[Bruce Stephens]

Richard Levitte - VMS Whacker <address@hidden> writes:

> In message <address@hidden> on Wed, 17 Nov 2004 13:34:23 +0000, Bruce 
> Stephens <address@hidden> said:
>
> monotone> Really what I'd like is to be left with a working tree with
> monotone> the conflicting files indicated in some way: then I can deal
> monotone> with them in an order that makes sense to me, and I can
> monotone> perform whatever sanity checks on the merged tree that make
> monotone> sense.  Then I can make sure that my merge cert actually
> monotone> means something about the revision.
>
> Basically, you're asking for a method that's very close to CVS',
> doing the merge in your work directory, let you do the work of
> fixing the differences, and finish it off with a commit.  The
> trouble I see is that monotone will probably have no chance to see
> the difference between a merging commit and a normal commit, and you
> will find yourself without a merge cert.  Do you have any ideas how
> to solve that?

Well, in isolation that's not hard: merge can add some suitable
information to whatever file it wants in MT, and then commit can use
that.  The catch is that potentially the working tree becomes
uncomfortably stateful, and I don't have a clean solution for that.  

I guess what I'm thinking is that there could be an --ancestor option
which could be used multiple times (or perhaps --ancestors, containing
space-separated ancestors), and merge could add that to MT/options.
But then suitable behaviour for all operations would need to be
determined, and you'd need to decide what to do if the working tree
already contained changes.  

Actually, maybe it would be best to require the creation of a new
working tree, and maybe in such a tree most operations are regarded as
simply invalid, since this is intended purely for merging.  That's
probably a bit expensive, I guess, for an operation that ought to be
entirely automatic most of the time.

> monotone> Can I do that in some way now?
>
> Very manually, by fetching each head separately, doing a merge using
> your favorite tool, do a commit with the result and add the
> corresponding certs manually.

OK, that seems workable.  Presumably if I set up hooks appropriately,
I can get things so that if merge doesn't need intervention then it'll
just work, and if it does, then it'll fail and I can do it the
expensive way by hand.  For example, I guess this would work:

function merge2(left, right)
    return nil
end
function merge3(ancestor, left, right)
    return nil
end

(Probably the "return nil" is unnecessary.)

[...]