monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] considering no merge-into-dir


From: graydon hoare
Subject: Re: [Monotone-devel] considering no merge-into-dir
Date: 08 Oct 2003 22:02:53 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Tom Tromey <address@hidden> writes:

> One reason I've wanted merge-into-dir is related to the user
> experience.  I'd like to be able to configure monotone to use merge3
> to construct a tree with `<<<<<' (etc) markers, like cvs, that I can
> then fix up and test at my leisure.  (That way I can use my existing
> Emacs instance to edit the files, instead of starting a new one each
> time.)

I strongly support improving the user experience here. I agree, if you
hit a really big, complex conflict right now the UI is sucks for
solving it. that needs fixing.

I only meant to point out that there's a good reason not to make such
"into a tree" behavior the default for all merges.

> I suppose most merges will be automatic.  Too bad we can't figure out
> ahead of time which ones are not -- these are the ones I'm most
> concerned about.

oh, I think we can. monotone asks for conflict help file-at-a-time
now, but there's no reason it must. it could try an auto-merge of
manifests, collect a list of files with conflicts, and write the whole
set of conflicts (with <<< markers, or .left / .right files, or
whatever) out to a tree for you to resolve. this type of improvement,
I don't object to.

(actually, a simple enough UI for this is to let "merge" take a
 directory full of "hints" -- merged files -- as an optional argument,
 and dump such a directory full of conflicts when it cannot
 auto-merge. good enough?)

but keep in mind, this is subtly different from "fixing bugs while
merging". this is "fixing conflicts". when you restart you will be
restarting a failed merge, not a successful one you want to sprinkle
some bug fixes on. 

there's a good reason, as I pointed out, to do those bug fixes in a
separate (later) step and let the successful auto-merge commit itself:
it means you and your colleague get a common ancestor lower down in
the ancestry graph, and your bug fixes are more likely to actually merge
with their later work cleanly.

> Finally, one other issue here is what to do when there are more than
> two heads.

I don't know why this is a different issue than just 2 heads. can you
elaborate?

-graydon





reply via email to

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