making memctx more generally useful

Sean Farley sean.michael.farley at gmail.com
Fri Jan 4 13:19:19 CST 2013


On Fri, Jan 4, 2013 at 12:42 PM, Steve Borho <steve at borho.org> wrote:
>
>
>
> On Fri, Jan 4, 2013 at 12:37 PM, Pierre-Yves David
> <pierre-yves.david at logilab.fr> wrote:
>>
>> On Wed, Jan 02, 2013 at 02:31:01PM -0600, Steve Borho wrote:
>> > Hello,
>> >
>> > I am in the middle of adding a record-like hunk selection feature to the
>> > TortoiseHg commit tool; using a patch based memctx to avoid having to
>> > repeatedly re-write working copy files and potentially bungling the
>> > dirstate.
>> >
>> > A problem that I have encountered (and based on a quick chat on IRC I am
>> > not the first) is that memctx.commit() directly calls into
>> > localrepo.commitctx() bypassing all the logic in localrepo.commit()
>> > which
>> > knows about subrepos, bookmarks, merge state, hooks, etc.
>>
>> I'm very happy to see this moving. With this problem solved we could ditch
>> the
>> temporary commit of amend.
>>
>> > For the short term; I am duplicating the functionality of
>> > localrepo.commit() within my partial commit function, but it seems like
>> > there is a lot of room for improvement here to make the
>> > localrepo.commit()
>> > functionality more reachable.
>> >
>> > Option #1 (minimal)
>> >
>> > add an optional getcctxfn=context.workingctx argument to
>> > localrepo.commit()
>> > so callers can inject their own commit context callback; using the
>> > changes
>> > list and other arguments that localrepo.commit() discovers
>> >
>> > Option #2
>> >
>> > Move localrepo.commit() functionality into workingctx, make memctx
>> > derive
>> > from workingctx
>> >
>> > Option #3
>> >
>> > Split localrepo.commit() into multiple functions which can be called a
>> > la
>> > carte
>>
>>
>> - Moving commit logic outside local repo would be a net win
>> - I'm not sure #2 solve alone the amend problem. We needs to:
>>   1) copy "." into a memctx,
>>   2) apply commit logic with content from the wctx to our memctx,
>>
>> A mix of #2 and #3 is probably the way to
>
>
> Thanks Pierre-Yves,
>
> When this was discussed on IRC; someone (I sometimes wish we kept IRC logs)
> mentioned they had a patch series that accomplished most of option #2.  Now
> would be a good time to post them, since it seems to be recognized as the
> best way to start this process.

Wasn't that Brodie? … or Mads? I forget who it was but they mentioned
merging with memctx about a year or so ago saying that it'd see the
light of day soon :-(


More information about the Mercurial-devel mailing list