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

Dan Villiom Podlaski Christiansen danchr at gmail.com
Sat Jan 7 08:53:57 CST 2012


On 7 Jan 2012, at 01:22, Matt Mackall wrote:

> 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?

Well, the issue is twofold: First of all, nothing good can come from these extensions intercepting conversion commits. In the best case, they simply disregard these conversion commits. In the worst case, they corrupt them. We *have* seen, however, problems with pulling certain revisions with both hgeol and hgsubversion enabled.

> 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.

Of those, prefer commitwctx()/commitctx(); although commitwctx/usercommitctx has no restrictions on the type of its argument, AFAICT it only deals with instances of workingctx. The single character difference strikes me as quite subtle; how about commitworkingctx()?

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com



More information about the Mercurial-devel mailing list