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

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

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

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

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

mergestate: simplify reset(), knowing that `other` and `node` go together There's only one caller of `reset()` that passes any arguments at all, and that originates from `merge.py:1371`. That code always passes values for both `node` and `other`. Differential Revision: https://phab.mercurial-scm.org/D9032

mergestate: make some callers not pass pointless node argument The node argument is set on the created `mergestate` instance, but these callers don't even look at that instance. Differential Revision: https://phab.mercurial-scm.org/D9031

py3: don't risk passing a None value to error.ManifestLookupError() This makes the test case added in 20dd2a259b0f (test-grep: add tests for --follow with/without --diff and/or paths, 2020-09-11) pass on Python 3. Differential Revision: https://phab.mercurial-scm.org/D9030

merge: move initial handling of mergeactions near to later one We build `mergeactions` in the beginning and use it in end. Let's build it just before where it will be used. Helps making code much easier to understand. Differential Revision: https://phab.mercurial-scm.org/D8983

upgrade: support running upgrade if repository has share-safe requirement This helps us in testing changing requirements of source repository and checking that the shared repository works. Differential Revision: https://phab.mercurial-scm.org/D8660

config: add `--shared` flag to edit config file of shared source With `format.exp-share-safe` enabled, we now read the `.hg/hgrc` of the shared source also. This patch adds `--shared` flag to `hg config` command which can be used to edit that shared source config file. It only works if the repository is shared one and is shared using the safe method. Differential Revision: https://phab.mercurial-scm.org/D8659

localrepo: load the share source .hg/hgrc also in share-safe mode (API) The second part of the Share Safe Plan is to share source repo config also. This patch adds logic to load the source repo .hg/hgrc if we are in share safe mode. On unshare, we copy and prepend source config to current repo so that config which was shared is persisted. A test is added to show that now if we enable a hook on the source repo, that also runs on the shared repositories. API change as a new optional argument sharedvfs added to localrepo.loadhgrc() Differential Revision: https://phab.mercurial-scm.org/D8656

helptext: document exp-sharesafe in internals/requirements.txt `exp-sharesafe` is a new requirement and we should document it. Differential Revision: https://phab.mercurial-scm.org/D8914

share: introduce config option to store requires in .hg/store This introduces a config option which enabled stores the requirements on a repository in store instead. When enabled, `.hg/requires` will contain the `share-safe` requirement which marks that the requirements are present in the store. This is done so that repository requirements can be shared with shares made using `hg share` command. After this patch, `hg share` checks whether the source repository has share-safe requirement, if yes, it does not copy the requirements. Test for the new functionality is added and a test case in exitsing share tests is also added. Differential Revision: https://phab.mercurial-scm.org/D8633

scmutil: introduce filterrequirements() to split reqs into wc and store ones In upcoming patches where we try to implement requirements in store, we will need a mechanism to split all requirements on some basis and decide which one goes to `.hg/requires` and which one goes to `.hg/store/requires`. This patch introduce a separate function for that. Filtering logic for now is put under an `if False:`. In upcoming patches it will be removed. Differential Revision: https://phab.mercurial-scm.org/D8913

remotefilelog: acquire lock before writing requirements on clone Performing a shallow clone in remotefilelog does not acquire lock. This leads to following warning when we try to write some requirements in store: ``` --- /home/gps/src/hg-committed/tests/test-remotefilelog-share.t +++ /home/gps/src/hg-committed/tests/test-remotefilelog-share.t#safe.err @@ -28,6 +28,7 @@ $ hgcloneshallow ssh://user@dummy/master source --noupdate -q + devel-warn: write with no lock: "requires" at: /home/gps/src/hg-committed/mercurial/scmutil.py:1505 (writerequires) $ hg share source dest updating working directory 1 files updated, 0 files merged, 0 files removed, 0 files unresolved ``` Let's lock before writing the requirements file. Another solution which I can think of is not warn about missing lock when writing to requires file in store. Differential Revision: https://phab.mercurial-scm.org/D8952

grep: make -frREV follow history from the specified revision (BC) This is close to what "log -frREV" will do, and is backported from 8b4b9ee6001a, "log: make -fr show complete history from the given revs" except for the "del opts['follow']" bit. I'm planning to rewrite cmdutil.walkchangerevs() to share the core logic with logcmdutil, and this is the first step towards that. There are still many broken tests, but the fundamental behavior should be fixed by this patch. .. bc:: `hg grep -fr REV` now follows history from the specified `REV`, works in the same way as `hg log -fr REV`. The previous behavior was to limit the search space to `REV` while following the history.

cmdutil: make walkchangerevs() gracefully handle wdir parents This code will be completely rewritten, but test-grep.t would fail without fixing it.

grep: fix --follow with no --diff nor --rev to not fall back to plain grep Before, "grep --follow" would only print matches in the working directory. Since --follow is the option to specify the search space, it should disable the plain (i.e. wdir) grep.

test-grep: add tests for --follow with/without --diff and/or paths This tests the behavior of cmdutil.walkchangerevs(). I'm going to rewrite cmdutil.walkchangerevs() to leverage the "log -f" logic, but the code coverage looked quite small. And the history traversal of "grep -f" goes wrong in various ways.

grep: clarify that --all works exactly the same way as --diff 7fbb5d76c555 "grep: add --diff flag" says as such, but the help strings have diverged since, and it's getting fuzzier what this --all will do.

churn: add an usage example in docstring

tests: run test-check-py3-compat only in pure python mode This test was added few years ago to detect syntax and import related warnings and kickstart the python-3 porting efforts. It tries to parse the ast and import the module. When using in strict modes like `HGMODULEPOLICY=rust` or `HGMODULEPOLICY=c`, the test fails. Let's run the test only on pure python mode. We now have full test suite being run with python 3 and some people even use hg with python 3 in production (like me).

log: make -frREV PATH detect missing files before falling back to slow path If -rREV isn't specified, "log --follow" would abort on nonexistent paths. Let's implement this behavior for "-frREV" case as we have ctx.hasdir() now. Otherwise "log -frREV PATH" would silently fall back to slow path and files wouldn't be followed across renames. The loop is quadratic (as before), but the size of the startctxs and match.files() should be small in general. Some tests are marked as BROKEN since file renames aren't tracked in the slow path. This is a known limitation of the current history traversal function.

log: fix -fr'wdir()' PATH to follow newly added file Testing filelog doesn't make sense in this case because the file existence is tested against the specified changectxs. If the filelog is empty and if startctxs != [wctx], 'f not in c' should be triggered.

log: reorganize if-else and for loop in logcmdutil._makematcher() The test conditions are branchy depending on --follow and --rev options, so it should be better to switch first by --follow --rev. Note that revs is not empty so "if follow and startctxs" can be replaced with "if follow and opts.get(b'rev')".

merge: update commitinfo from all mergeresults during bid merge During bid merge, it's not clear which commitinfo should be stored and which one should not. This depends on which side the bid merge chooses for a file. For this we will need to refactor bid merge code and commitinfo handling. For now, we just blindly updates info since we hardly have any users of commitinfo and this will help us in testing and clearing out further path. Differential Revision: https://phab.mercurial-scm.org/D8965

merge: add missing ACTION_KEEP when both remote and ancestor are not present Previous patch may lead to confusion that the related criss-cross merge is consistent when done from any of the parents. However this is not true and we were missing setting an ACTION_KEEP. This patch now exposes that bid-merge favors ACTION_KEEP always and the result of merge is different when started from different parents. This change also effects a test case above where bid merge was wrongly picking `r` because it was missing keep related information from one of the ancestor. After this test, we are back in a state in the criss-cross merge tests where the result depends on which parent we are merging from. Differential Revision: https://phab.mercurial-scm.org/D8941

merge: store ACTION_KEEP_ABSENT when we are keeping the file absent locally If a file is not present on the local side, and it's unchanged between other merge parent and ancestor, we don't use any action, neither we had a if-else branch for that condition. This leads to bid-merge missing that there is a such action possible which can be performed. As test changes demonstrate, we now choose the locally deleted side instead of choosing the remote one consistently. This is also wrong behavior which is resulted because of missing possible action. It will be fixed in next patch. This whole logic is not acurrate as we should prompt user on what to do when this kind of criss-cross merge is in play. Differential Revision: https://phab.mercurial-scm.org/D8940

merge: add `ACTION_KEEP_ABSENT` to represent files we want to keep absent There are files which were deleted/not present in working copy parent but were present on other side of merge. On merge, we might decide to keep them deleted. We want to track such cases more closely, rather all kind of cases which results from some kind of merging logic. We do have `ACTION_KEEP` but having a dedicated action for the absent case is more cleaner. Initially I named the action as `ACTION_KEEP_DELETED` but later realized that file can be not-present because of other reasons than deletion like rename, hence decided to use more generic name `ACTION_KEEP_ABSENT`. Differential Revision: https://phab.mercurial-scm.org/D8974