Pulkit Goyal <7895pulkit@gmail.com> [Mon, 14 Sep 2020 13:51:39 +0530] rev 45466
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 13:27:46 +0200] rev 45465
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
Kyle Lippincott <spectral@google.com> [Fri, 11 Sep 2020 15:52:06 -0700] rev 45464
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
Joerg Sonnenberger <joerg@bec.de> [Thu, 23 Jul 2020 20:23:44 +0200] rev 45463
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
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 14 Sep 2020 11:32:24 -0400] rev 45462
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 06:15:06 +0200] rev 45461
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jun 2020 06:04:48 +0200] rev 45460
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.
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 26 Aug 2020 17:20:53 +0530] rev 45459
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
Yuya Nishihara <yuya@tcha.org> [Mon, 14 Sep 2020 19:39:51 +0900] rev 45458
merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:52:24 +0900] rev 45457
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.