[Top][All Lists]

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

Re: [Monotone-devel] Non-modal merge

From: Ralf S. Engelschall
Subject: Re: [Monotone-devel] Non-modal merge
Date: Sun, 23 Sep 2007 12:46:54 +0200
User-agent: Mutt/1.5.16 OpenPKG/CURRENT (2007-06-09)

On Sat, Sep 22, 2007, Stephen Leake wrote:

> Stefan Monnier <address@hidden> writes:
> > Bak when I used monotone for the first time, I was surprised to see that
> > all the merge options provided were pretty much modal.  So I came up with
> > the code attached below (not on my own, it's largely copied from random
> > bits on the Web, it's probably hideous for Lua experts).
> >
> > Is there such a tool in standard now?
> Not in standard, but I put one in
> contrib/diff3_keep_conflicts_merger.lua
> The objection is that this allows conflicts to be commited to the
> database.
> In most situations, I don't have a problem with that, and I definitely
> prefer the non-modal behavior; often I don't have time to fix all
> the conflicts immediately.
> If you don't want the conflicts committed, you can use
> merge_into_workspace, although that has other problems. For one thing,
> it's undocumented :). For another, it leaves the workspace with two
> parents, which is not typical, and Emacs DVC can't handle it (yet).

I've now improved my "diffutils" merger implementation in std_hook.lua.
One now can use MTN_MERGE_DIFFUTILS=partial to get the results
of contrib/diff3_keep_conflicts_merger.lua. When combined with
"merge_into_workspace" as in...

$ MTN_MERGE=diffutils_new MTN_MERGE_DIFFUTILS=partial mtn merge_into_workspace now gets mostly the operation one is used from "cvs update" and
"svn update", i.e. a revision is merged into the workspace and conflicts
are marked for further manual editing before comitting.

> It would be nice if the top-level merger code output a summary of
> conflicts in this case, so it would be easier to keep a list of things
> to go back and fix, but the current output isn't too bad for that purpose.

I think one needs something like a "mtn list conflicts" which checks
whether any files still contain conflict markers.

> There was some discussion of having mtn keep track of the conflicts,
> but I think that's unnecessary.
> One difference between our scripts is that I ignore the return value,
> while you check for ret > 1. I guess diff3 returns 1 for "conflict",
> and > 1 for "error"? The man page I have (in Cygwin) doesn't document
> the return value.

It returns 0 for success, 1 for conflict and 2 for error.

> Feel free to improve contrib/diff3_keep_conflicts_merger.lua

I felt free and merged your stuff into my "diffutils"
merger in std_hooks.lua. I think we can now even remove

                                       Ralf S. Engelschall

reply via email to

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