[PATCH RFC] merge: experimental attempt at removing prompts from merge command

Steve Borho steve at borho.org
Sun Nov 7 20:16:37 CST 2010

On Sun, Nov 7, 2010 at 6:53 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2010-11-02 at 19:43 -0500, Steve Borho wrote:
>> On Sun, Oct 10, 2010 at 2:51 PM, Steve Borho <steve at borho.org> wrote:
>> > # HG changeset patch
>> > # User Steve Borho <steve at borho.org>
>> > # Date 1286672233 18000
>> > # Node ID 79ab8c99b5743eb0fdd867c2cf27848d0ac64842
>> > # Parent  c6cdc123f6e4da831ca577044f5b5aefdad929f1
>> > merge: experimental attempt at removing prompts from merge command
>> Posting this again to re-open discussion.
> Actually, you're replying to yourself which is a very different thing:
> it doesn't put a patch I can apply where I can easily find it (namely in
> my inbox).
> But anyway, how does this thing work? How does it store conflicts that
> aren't normal merge conflicts? How is it going to store new types of
> conflicts we invent and how is that going to avoid breaking older
> versions?

This patch introduces a sister file to .hg/merge/state named
.hg/merge/mstate.  Where `state' holds files with content conflicts,
`mstate' holds files with manifest conflicts, meaning the file's
manifest entry is in conflict.  In current Mercurial, there are two
classes of manifest conflicts:

* one side modified a file, the other side deleted it
* on one side the file is executable, on the other it is a symlink

The format of the mstate file is similar to state, but needs much less data.

Older versions of Mercurial will not recognize mstate, so they will
assume the manifest conflicts were resolved during the initial merge -
which is safe.  Older Mercurial versions can still revert to one
parent or the other to change the manifest resolve selection.  When
the commit is made, all of .hg/merge is deleted, so we won't leak
mstate files.

>> > With this patch, manifest conflicts are not restartable as content conflicts
>> > are.
> Why? Is this a corner that's being cut for now or is it something we're
> going to be stuck with?

It's a corner being cut.  These manifest merges could be restarted
since all of the data is in the repository.

Steve Borho

More information about the Mercurial-devel mailing list