[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] considering no merge-into-dir
From: |
Zack Weinberg |
Subject: |
Re: [Monotone-devel] considering no merge-into-dir |
Date: |
Wed, 08 Oct 2003 20:48:33 -0700 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
graydon hoare <address@hidden> writes:
> 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'm tired and not thinking clearly, but I would like to make two
observations:
1) A useful thing to do on conflict is to create three files with
names predictably derived from the base filename: (for example)
foo.c.GCA, foo.c.LEFT, foo.c.RIGHT. With the obvious contents.
It is then possible to apply an intelligent third-party merge
program such as Ediff (part of Emacs) or the spiffy gui one that
comes with MacOS X that I can't remember the name of.
2) Regarding the scenario you described earlier, how does this sound?
If there's no machine-unresolvable conflict, automatically commit
the merge. If there *is* a machine-unresolvable conflict, commit
what would be committed now, but then immediately modify the file
again, laying down CVS-style conflict markers. and refuse to let
the user commit it until they've resolved the conflict.
The graph that would then be produced from your scenario looks
something like this:
... PARENTPIE --- TROMEYPIE -- AUTOMERGED --- TROMEYFIX
\-- GRAYDONPIE --/ (broken) \-- NJS_doesnt_care_about_pies
which I believe is the same graph you end up with by leaving stuff
alone. This is *effectively* what CVS does if the merge is machine
resolvable, and if the merge isn't machine resolvable it is enough
like what CVS does to satisfy principle of least surprise.
I hope I explained that coherently.
zw
- [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, 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