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