[PATCH 1 of 5] localrepo: add usercommitctx() wrapper

[Matt Mackall]

On Fri, 2012-01-06 at 15:16 +0100, Dan Villiom Podlaski Christiansen
wrote:
> # HG changeset patch
> # User Dan Villiom Podlaski Christiansen <danchr at gmail.com>
> # Date 1325855014 -3600
> # Node ID f3f1a59f7bdba614d3aeeef3423a30105b3f013b
> # Parent  f15c646bffc7187c357f3dcc12761513c1ed6609
> localrepo: add usercommitctx() wrapper
> 
> This wrapper allows extensions to safely wrap commitctx() for
> user-initiated commits only.
>
> Fundamentally, there are two kinds of client of the commitctx() API:
> - localrepository.commit().
> - conversion extensions such as convert, hgsubversion and hg-git.
> 
> When an extension wraps or specialises commitctx() instead of
> commit(), it's often because it needs to access the context being
> committed. However, commitctx() is the sole API for adding changesets
> to the repository, and for this reason, it is also used by the
> conversion extensions. The needs of these extensions typically
> conflict with wrapping commitctx(), as it is important that their
> contexts are committed unmodified, as-is to the repository.

Not sure about this.

If hg-git is incompatible with eol, keyword, and largefiles, shouldn't
it be hg-git that is proactively ensuring it's using the native
commitctx?

Alternately, we can do:

def commitctx(self, ...):
    return self._commitctx(...)

and then hg-git can call _commitctx if available?

But I guess what you're really getting at is that there's "commit from
the working directory using whatever extensions and crap" and "internal
commit". So we're perhaps talking about commitwctx vs commitctx or
perhaps commitctx vs commitmemctx.

-- 
Mathematics is the supreme nostalgia of our time.