[PATCH 2 of 2] convert: execute merges in-memory (issue5076)

Sean Farley sean at farley.io
Tue Feb 23 16:45:55 EST 2016


Tony Tung <tonytung at instagram.com> writes:

>> On Feb 23, 2016, at 1:13 PM, Sean Farley <sean at farley.io> wrote:
>> 
>> 
>> Augie Fackler <raf at durin42.com> writes:
>> 
>>>> On Tue, Feb 23, 2016 at 12:14:00AM -0800, Tony Tung wrote:
>>>> # HG changeset patch
>>>> # User Tony Tung <tonytung at merly.org>
>>>> # Date 1456215137 28800
>>>> #      Tue Feb 23 00:12:17 2016 -0800
>>>> # Node ID b7f61d7438ba1aed06afa1a53a2b5fda8bdc225f
>>>> # Parent  cbc605f28b61cc469e21186982d0569bf94f7d2a
>>>> convert: execute merges in-memory (issue5076)
>>> 
>>> I think this makes sense. Sean, you've done in-memory merge stuff,
>>> does this look sensible at least for convert to you?
>> 
>> My spider senses did go off with the subject line but I don't really see
>> what is changing here. There's a change in the method signature and a
>> check for it later but everything else with the merge machinery
>> (workingctx and its interaction with wwrite) remains untouched. Perhaps
>> the 'hg convert' code path takes a different route? I'm guessing Tony is
>> referring to merging the manifest (and not the other machinery I
>> mentioned)?
>> 
>> If so, then it seems this 'inmemoryonly' argument might be used (perhaps
>> by me) later for a first attempt of a pure in-memory merge.
>
> The hg convert path will not check for dirty subrepos because the working copy remains untouched throughout the entire conversion process.

Ok, so this has nothing to do with an actual in-memory merge. Just
converting without touching the working directory.


More information about the Mercurial-devel mailing list