[Top][All Lists]
[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
- [Monotone-devel] considering no merge-into-dir, graydon hoare, 2003/10/08
- Re: [Monotone-devel] considering no merge-into-dir, Tom Tromey, 2003/10/08
- Re: [Monotone-devel] considering no merge-into-dir,
graydon hoare <=
- Re: [Monotone-devel] considering no merge-into-dir, Tom Tromey, 2003/10/09
- Re: [Monotone-devel] considering no merge-into-dir, graydon hoare, 2003/10/09
- Re: [Monotone-devel] considering no merge-into-dir, Zack Weinberg, 2003/10/10
- Re: [Monotone-devel] considering no merge-into-dir, graydon hoare, 2003/10/12