[PATCH 2 of 6] filemerge: turn filemerge into a generator

Matt Mackall mpm at selenic.com
Sun Oct 11 11:38:25 CDT 2015


On Fri, 2015-10-09 at 11:46 -0700, Siddharth Agarwal wrote:
> # HG changeset patch
> # User Siddharth Agarwal <sid0 at fb.com>
> # Date 1444371736 25200
> #      Thu Oct 08 23:22:16 2015 -0700
> # Node ID 66ed0fddfd25ea6070c578d0c58e4d198e9236d1
> # Parent  f32ecec8697102c6daeda1f3a98711a8305f928d
> filemerge: turn filemerge into a generator

> As described in the previous patch, we separate out premerge and merge into
> separate steps.

Recently there was a BTS discussion about aborting huge merges[1]. My
contention there is that we actually have to do ALL the premerges before
ALL the merges. This gives us two things: a maximally complete state
before we involve the user and a notion of how many actual merges
they'll have to do (which we can report and/or use to just drop them to
resolve if they're over some threshold).

When you were talking about separate steps, I'd actually assumed this is
what you were aiming for. But it doesn't seem to be?

Let's instead just pass a flag that says premerge=True|False|None (= do
both) to filemerge, pass it through mergestate.resolve and have two
loops in applyupdates. We'll redo some work, yes, but in practice most
of the premerges should be successful so we'll never do the second pass.

Also, I think mergectx is no good as a name. If it's not in context.py,
it probably shouldn't be a "ctx". But it shouldn't be needed if we do
the above.

[1] Which apparently only like two people read and I can't even find
now, which is why you should never use the BTS for design discussion.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list