context: set repo property in basectx It seems like a good practice to call the super constructor. Let's start by passing the repo along to basectx so it can assign it to a private attribute. We should perhaps pass the rev and node along as well, but that requires more work before it can be done. Differential Revision: https://phab.mercurial-scm.org/D2970

context: move reuse of context object to repo.__getitem__ (API) As an example of how weird the basectx.__new__ is: whenever you create a workingctx, basectx.__new__ gets called first. Since our __new__ has a "changeid" argument as second parameter, when create the workingctx(repo, text="blah"), the text gets bound to "changeid". Since a string isn't a basectx, our __new__ ends up not doing anything funny, but that's still very confusing code. Another case is metadataonlyctx.__new__(), which I think exists in order to prevent metadataonlyctx.__init__'s third argument (originalctx) from being interpreted as a changeid in basectx.__new__(), thereby getting reused. Let's move this to repo.__getitem__ instead, where it will be pretty obvious what the code does. After this patch, changectx(ctx) will be an error (it will fail when trying to see if it's a 20-byte string). Differential Revision: https://phab.mercurial-scm.org/D2969

memctx: create parent contexts using "repo[p]" syntax I want to reduce dependence on basectx.__new__() and move that code over to repo.__getitem__(). Differential Revision: https://phab.mercurial-scm.org/D2968

context: avoid using a context object as a changeid I find it misleading to pass changeid=changectx. It currently works to do that because there's weird (IMO) handling of it in basectx.__new__. I'm planning on removing that code. Passing changeid as "changeid" and context as "context" makes it more readable. Note that the documentation of filectx.__init__ doesn't even seem to be aware that a changeid can be a context ("changeset revision, node, or tag"). Differential Revision: https://phab.mercurial-scm.org/D2967