Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Sep 2020 16:10:16 -0700] rev 45510
merge: use in-memory mergestate when using in-memory context
This is my version of Augie's D8568. It makes it so we don't touch the
mergestate on disk when using an in-memory context.
The reason that I want this is not the same as the reason that Augie
write his patch (though I agree with that reason too). My hope is to
make in-memory rebase not fall back to on-disk rebase when there are
conflict. I plan to do that by adding a
`overlayworkingctx.reflect_in_workingcopy()`. The idea is that that
will update the working copy, the dirstate and the mergestate as
necessary.
Differential Revision: https://phab.mercurial-scm.org/D9040
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Sep 2020 11:17:24 -0700] rev 45509
mergestate: extract a base class to be shared by future memmergestate
This extracts a new base class from `mergestate` and leaves all the
vfs-touching code in `mergestate`.
Differential Revision: https://phab.mercurial-scm.org/D9039
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Sep 2020 11:33:26 -0700] rev 45508
mergestate: extract overridable methods for making/restoring file backups
In-memory merge currently still uses on-disk mergestate. That's mostly
harmless (I don't think I've seen any problem it's actually
caused). It's still a little weird. I'm planning to add an in-memory
mergestate, which will be used with `overlayworkingctx`. This patch
prepares for that by extracting that logic, so it's easier to change
per subclass.
Differential Revision: https://phab.mercurial-scm.org/D9038
Martin von Zweigbergk <martinvonz@google.com> [Wed, 16 Sep 2020 13:39:26 -0700] rev 45507
mergestate: initialize all properties in __init__()
This is hopefully not very controverial. I found the initialization
before this patch unorthodox. It wasn't clear which properties the
object was supposed to have.
Differential Revision: https://phab.mercurial-scm.org/D9037
Martin von Zweigbergk <martinvonz@google.com> [Thu, 17 Sep 2020 19:33:55 -0700] rev 45506
mergestate: remove unnecessary clearing of `localctx` and `otherctx`
As noted in the previous commit, there are no callers that (re-)use
the instance after calling `reset()`. There are also no callers that
call `_read()` after doing anything with the instance (it's only
called right after an instance is created).
If reviewers feel that this is too risky, I can extract and reuse the
poisoning code that indygreg once added for poisining repo instances.
Differential Revision: https://phab.mercurial-scm.org/D9036
Martin von Zweigbergk <martinvonz@google.com> [Wed, 16 Sep 2020 13:25:49 -0700] rev 45505
mergestate: move most of of reset() into start()
`ms.reset()` has somehow become a combination of two different things:
1. A constructor-like function creating an empty instance
2. A call to `shutil.rmtree()` to clear the mergestate.
It seems that all callers now care only about the latter (since we
changed one caller to use the new `ms.start()` method instead). Let's
move the code for the former into `start()`, since that's the only
place it's needed.
Differential Revision: https://phab.mercurial-scm.org/D9035
Martin von Zweigbergk <martinvonz@google.com> [Thu, 17 Sep 2020 09:23:21 -0700] rev 45504
mergestate: make clean() only be about creating a clean mergestate
This is similar to the previous patch, but moves the separation one
step further out, to `merge.py`.
Differential Revision: https://phab.mercurial-scm.org/D9034
Martin von Zweigbergk <martinvonz@google.com> [Wed, 16 Sep 2020 10:09:37 -0700] rev 45503
mergestate: split up reset() for its two use cases
We only have one place that calls `ms.reset()` with any
arguments. That place is `mergestate.clean()`. The callers that call
the function with no arguments seem to all just want delete the
mergestate -- none of them look at the instance after calling
`reset()`. Let's separate out the two different use cases to make the
code clearer. I'll clean up further soon.
Differential Revision: https://phab.mercurial-scm.org/D9033