making memctx more generally useful

[Matt Mackall]

On Wed, 2013-01-02 at 14:31 -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.
> 
> 
> 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
> 
> 
> Preferences?  Other options?

#2 is the most interesting to me, but I think you need to check with:

- the hg-git and hg-subversion folks
- the keyword extension guy

-- 
Mathematics is the supreme nostalgia of our time.