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

mergeresult: introduce dedicated tuple for no-op actions This will help us in adding more no-op actions in next patch while keeping the code cleaner.

tests: add criss cross merging tests whose behavior need to be fixed Merging two changesets can mark a file as removed post merge. However, in some cases, a user might not want to remove that file and they revert the removal back and commit the merge. All this works perfectly well. However, when we do criss-cross merges with such merge where user explicitly choose to revert the removal with one where another user choose the removal, we does not get any conflict. The intent here is conflicting and merge should result in conflicts. One user merged and want to keep the file while other user merged and want to remove the file. Merging those merges should result in conflicts. This patch adds test cases for these cases. Differential Revision: https://phab.mercurial-scm.org/D8939

repo: avoid copying/updating a dict on every `repo.__getitem__` This has some mild performance benefits. I'm looking into a pathological case where one of our `hg log` invocations takes several seconds, and according to hyperfine this reduces the wall time of the entire operation (running in chg) from: ``` Time (mean ± σ): 7.390 s ± 0.106 s [User: 7.058 s, System: 0.271 s] Range (min … max): 7.300 s … 7.625 s ``` to: ``` Time (mean ± σ): 7.046 s ± 0.091 s [User: 6.714 s, System: 0.279 s] Range (min … max): 6.916 s … 7.169 s ``` Note: the log command is slow due to an issue in our custom stuff executing `repo[<arg>]` 298,800 times. This performance improvement is likely not noticeable during normal operation, but I don't feel like it's making the code more difficult to understand, and every small bit helps. Differential Revision: https://phab.mercurial-scm.org/D9022

obsstore: refactor v1 logic to fix 32 byte hash support Refactor the v1 logic to determine the node parsing based on the flag. Move the predecessor out of the fixed part and handle it like the other nodes, removing most of the duplicated code for parsing 20/32 bytes hashes. Differential Revision: https://phab.mercurial-scm.org/D8801

fsmonitor: increase the threshold before we recommend it, when using rust 50k files works just fine with the rust status, and it's annoying to get told "consider using fsmonitor" when we have another solution to the status speed. 400k files was not chosen in any rigorous way. I know 200k files is fine. Twice as many files should still be fine. Differential Revision: https://phab.mercurial-scm.org/D9021

copy-tracing: test case where a merge reverted a file deletion This case is currently broken for commit centric copy tracing. So we add an official case for it with a note about it being broken. Fixing it will requires multiples change in code related to merge, commit and copy tracing, so we introduce it beforehand for simplicity. Also, I have been sitting on this test for 3 months so I would rather have it upstream.

copy-tracing: test case where we go across a changed/deleted merge This case is currently broken in the commit centric case. So we add an official case for it with a note about it being broken. Fixing it will requires multiples change in code related to merge, commit and copy tracing, so we introduce it beforehand for simplicity. Also, I have been sitting on this test for 3 months so I would rather have it upstream.

merge: show list of bids for each file in bid-merge in ui.debug() Earlier, we were showing the list of bids only when we were ambiguously picking. However, the cases where we unambiguously picked a side may not always be correct and need to be fixed. Having list of bids for all files will be helpful in debugging. Differential Revision: https://phab.mercurial-scm.org/D8966

merge with stable

cmdutil: reimplement finddate() without using walkchangerevs() It's simpler and slightly faster maybe because a fewer Python ops would run. Unscientific benchmark: $ python -m timeit \ -s 'from mercurial import hg, ui, cmdutil; repo = hg.repository(ui.ui())' \ 'cmdutil.finddate(repo.ui, repo, "<2008-01-01")' (orig) 10 loops, best of 3: 1.45 sec per loop (new) 10 loops, best of 3: 1.25 sec per loop Now "hg churn" and "hg grep" are the only users of walkchangerevs(), which I want to refactor and fix bugs.

test-simple-update: add test for -d DATE option I couldn't find any tests for cmdutil.finddate() except for the abort case.

largefiles: walk history in ascending order while downloading all lfiles I don't think the order matters. Maybe it's purely because of the use of walkchangerevs(), which was originally designed for "hg log" command. Surprisingly, the number of objects fetched in test-largefiles.t has changed. According to the --verbose output, the order of the following fetches flipped and the latter got deduplicated. getting large3:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store getting sub/large4:eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 found eb7338044dc27f9bc59b8dd5a246b065ead7a9c4 in store

largefiles: replace use of walkchangerevs() with simple revset query Since it does nothing in prepare(), what we're doing is just walking revisions matching ".hglf" in reverse order.

largefiles: remove unused 'rev' parameter from downloadlfiles() It's no longer used since 83ead8cb0ff2 "largefiles: implement pull --all-largefiles as a special case of --lfrev."

resourceutil: document when we expect to take the importlib.resouces code path Differential Revision: https://phab.mercurial-scm.org/D9018

templater: fix reading of templates in frozen binaries with py3 < 3.7 When using a frozen binary with py3 < 3.7, there's no `importlib.resources` module, so we use the code path that reads the resources from the file system. That code path expects bytes for package name and resource name. Differential Revision: https://phab.mercurial-scm.org/D9008

histedit: cache description line Navigating the curses-based histedit interface can be pretty slow because it redraws everything whenever you make a change. This patch simply replaces `@property` by `@util.propertycache` on the `histeditrule.desc()` function so it's not re-calculated every time the screen needs to be re-rendered. I timed it on an example of 30 simple commits, where I moved the top commit down 25 steps and then up 25 steps after. Before this patch, that (the whole `hg histedit` invocation) took 11.6 s of CPU and after this patch it took 0.8 s). Differential Revision: https://phab.mercurial-scm.org/D9016

tests: make emacs test less strict It was failing like this for me: ``` @@ -2,7 +2,7 @@ $ emacs -q -no-site-file -batch -l $TESTDIR/../contrib/hg-test-mode.el \ > -f ert-run-tests-batch-and-exit Running 1 tests (*) (glob) - passed 1/1 hg-test-mode--compilation-mode-support + passed 1/1 hg-test-mode--compilation-mode-support (0.045732 sec) - Ran 1 tests, 1 results as expected (*) (glob) + Ran 1 tests, 1 results as expected, 0 unexpected (2020-09-11 16:49:56+0000, 0.046034 sec) ``` Differential Revision: https://phab.mercurial-scm.org/D9017

graphlog: use '%' only if there are *unresolved* conflicts In 14d0e89520a2, I made graphlog use '%' for the "other" context when there's an existing merge state. However, that has confused many people because it shows up even if all conflicts are already resolved, which makes it show up even after e.g. `hg update -m` with automatically resolved conflicts. This patch makes it so we show the '%' only if there still unresolved conflicts. This patch replaces my earlier attempt in D8930, where I decided to automatically clear the mergestate if there are no remaining conflicts. That had the problem that it wouldn't let the user re-resolve the conflicts using `hg resolve`. Note that an in-progress "proper" merge (one that will result in a commit with two parents, such as after `hg merge`) will already have two dirstate parents before the commit happens. That means that both sides of the merge will get drawn as '@' in the graph, since "is dirstate parent" takes precedence over "is involved in merge conflict". Differential Revision: https://phab.mercurial-scm.org/D9007

merge: show number of ancestors in bid merge debug notes A good number of times, we don't generate an action for a file in manifestmerge() which can result in bid merge doing the wrong thing. Mentioning the number of ancestors from which we are bidding will help spot such cases where we are not returning an action. Differential Revision: https://phab.mercurial-scm.org/D8967

debugmergestate: sort extras before printing Prevents flaky output. Differential Revision: https://phab.mercurial-scm.org/D8986

debugmergestate: show extras for files which are not in mergestate With recent changes and future changes, we will like to store extras information about files which were merged automatically. Hence, we will have merge extras for files which are not in the mergestate. Differential Revision: https://phab.mercurial-scm.org/D8942

tests: update lockdelay.py to handle the `wait` argument Spotted by a future change.

commit: pass mergestate into _filecommit() instead of re-reading it mergestate reading although cheap is not free. Let's read mergestate once on top and pass it into `_filecommit()`. In upcoming patches, we will be reading mergestate more in `_filecommit()`. Differential Revision: https://phab.mercurial-scm.org/D8984

py3: fix bytes and str mixup in run-tests Differential Revision: https://phab.mercurial-scm.org/D9009

hg-core: fix some `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8957

rhg: print error message when argument parsing fails Differential Revision: https://phab.mercurial-scm.org/D8956

rhg: fix `clippy` warnings Differential Revision: https://phab.mercurial-scm.org/D8955

rhg: pass `ui` to `Command` `run` Allow implementation of `From<clap::ArgMatches> for Command` Differential Revision: https://phab.mercurial-scm.org/D8954

rhg: add harness tests for rhg files Differential Revision: https://phab.mercurial-scm.org/D8873

rhg: make output of `files` relative to the current directory and the root This matches the behavior of `hg files`. The util is added in `hg-core` instead of `rhg` because this operation could be useful for other external tools. (this was definitely not prompted by rust issue #50784, I swear) Differential Revision: https://phab.mercurial-scm.org/D8872

tags: take lock instead of wlock before writing hgtagsfnodes1 cache This cache is shared across stores and hence we should take store lock before writing to it. Otherwise there will be race where one share with wlock is writing to this cache and other share with wlock is trying to read it simultaneously. Differential Revision: https://phab.mercurial-scm.org/D9001

statichttprepo: use LockUnavailable() instead of Abort() for lock (API) If we try to get a lock on statichttprepo, we get `error.Abort()` instead of subclass of `error.LockError()`. The callers which catches `error.LockError` fails to catch this case as the correct error is not raised. Raising `error.LockUnavaible()` is same as what is done for wlock also.

localrepo: warn if we are writing to cache without a lock From quite sometime we have two types of cache, `cache` and `wcache`. The later one is a working copy cache and the first one is a store cache. Let's add a check for warning if we are missing store lock while writing to these caches. This is inspired from some tag cache breakage which is observed when multiple shares are in play. The interesting part is that although we are still taking wlock to write store caches at many places, but still the test pases. Differential Revision: https://phab.mercurial-scm.org/D9000

commit: fix a wrong argument name in documentation Differential Revision: https://phab.mercurial-scm.org/D8985

git: remove unrequired assignment of listignored and listunknown Caught by test-check-pyflakes.t

grep: fix hash(linestate) to not include linenum linestate.__eq__() just compares the line values whereas __hash__() does hash both self.line and self.linenum, which violates the rule. __hash__() was added at fb502719c75c, "python 2.6 compatibility: add __hash__ to classes that have __eq__" with no additional remarks, so this would probably be a simple mistake. The test output changed because difflib.SequenceMatcher() internally uses a dict. As you can see, the line "export" is unchanged at the revision 2, so the new output is correct.

test-grep: document that trivially moved lines might not be detected I'm not going to fix this. I just learned "grep --diff" does clever thing than a simple grep(patch.diff(context=0)), and I think it's better to document how things work.

revset: remove indirect indexing of status tuple Just use the attribute name.