[PATCH 3 of 5] workingctx: add a way for extensions to run code at status fixup time

[Sean Farley]

Siddharth Agarwal <sid at less-broken.com> writes:

> On 6/12/17 3:59 PM, Sean Farley wrote:
>> The ownership could be in localrepo, for sure. But the methods could
>> still live in workingctx (and just call self._repo._dirstate). I'm also
>> ok with doing the refactor myself and can queue this as-is.
>
>
> Hmm, that might be inconvenient for extensions that need to use it, 
> since (as in patch 4) they may plug in at the dirstate.status or 
> localrepo.status level.

localrepo.status is just a call (and I guess could be deprecated
now) for wctx.status. I think dirstate.status is fine where it is.

> Seems to me that creating a wctx through repo[None] just to mutate some 
> state that lives on the localrepo anyway is unnecessarily indirect.

I'm hoping it won't be but you might have a point here. My goal is to
more or less make interacting with a repo through context objects (this
could have the side-effect of making localrepo immutable). To that
extent, my current plan is to have anything touching the working
directory go through a workingctx (dirstate, wvfs, etc.)

> This might make a bit more sense once dirstate is in workingctx, I 
> guess. (I don't know what your plans are around dirstate uniqueness -- 
> if the dirstate object isn't destroyed on invalidation like it is today, 
> then this state can live there.)

For now, I'm leaving dirstate in the localrepo (and changing it to
repo._dirstate).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170612/ae6d6702/attachment.asc>