making memctx more generally useful

[Steve Borho]

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.

It would be good to hear from Augie as well about how this would help/harm
hgsubversion and hg-git.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130104/9670d18e/attachment.html>