Sun, 13 Sep 2020 18:14:51 +0900 test-simple-update: add test for -d DATE option
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 18:14:51 +0900] rev 45456
test-simple-update: add test for -d DATE option I couldn't find any tests for cmdutil.finddate() except for the abort case.
Sun, 13 Sep 2020 17:46:48 +0900 largefiles: walk history in ascending order while downloading all lfiles
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:46:48 +0900] rev 45455
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
Sun, 13 Sep 2020 17:43:19 +0900 largefiles: replace use of walkchangerevs() with simple revset query
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Sep 2020 17:43:19 +0900] rev 45454
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.
Fri, 11 Sep 2020 10:47:17 +0900 largefiles: remove unused 'rev' parameter from downloadlfiles()
Yuya Nishihara <yuya@tcha.org> [Fri, 11 Sep 2020 10:47:17 +0900] rev 45453
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."
Sat, 12 Sep 2020 11:18:12 -0700 resourceutil: document when we expect to take the importlib.resouces code path
Martin von Zweigbergk <martinvonz@google.com> [Sat, 12 Sep 2020 11:18:12 -0700] rev 45452
resourceutil: document when we expect to take the importlib.resouces code path Differential Revision: https://phab.mercurial-scm.org/D9018
Thu, 10 Sep 2020 22:00:00 -0700 templater: fix reading of templates in frozen binaries with py3 < 3.7
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 22:00:00 -0700] rev 45451
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
Fri, 11 Sep 2020 09:35:49 -0700 histedit: cache description line
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:35:49 -0700] rev 45450
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
Fri, 11 Sep 2020 09:55:08 -0700 tests: make emacs test less strict
Martin von Zweigbergk <martinvonz@google.com> [Fri, 11 Sep 2020 09:55:08 -0700] rev 45449
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
Thu, 10 Sep 2020 13:12:34 -0700 graphlog: use '%' only if there are *unresolved* conflicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Sep 2020 13:12:34 -0700] rev 45448
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
Wed, 26 Aug 2020 17:24:22 +0530 merge: show number of ancestors in bid merge debug notes
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 26 Aug 2020 17:24:22 +0530] rev 45447
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip