Tue, 18 Jun 2019 23:23:30 -0700 tests: demonstrate missing copy information in working copy with graphlog
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:23:30 -0700] rev 42501
tests: demonstrate missing copy information in working copy with graphlog Differential Revision: https://phab.mercurial-scm.org/D6543
Wed, 19 Jun 2019 10:33:13 -0700 remotefilelog: handle copies in changesets in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:33:13 -0700] rev 42500
remotefilelog: handle copies in changesets in getrenamedfn() override E.g. the {file_copies} template keyword didn't work with copies in changesets before this patch because remotefilelog overrides the getrenamedfn() and didn't handle the changeset-centric case. Differential Revision: https://phab.mercurial-scm.org/D6542
Wed, 19 Jun 2019 11:12:06 -0700 remotefilelog: check if RFL is enabled in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 11:12:06 -0700] rev 42499
remotefilelog: check if RFL is enabled in getrenamedfn() override In 8a0e03f7baf4 (remotefilelog: move most setup from onetimesetup() to uisetup(), 2019-05-01), I said: All the wrappers moved in this patch check if remotefilelog is enabled before they change behavior, so it's safe to always wrap. That was clearly a lie, because getrenamedfn() didn't. That made e.g. `hg log -T {file_copies}` unbearably slow. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6541
Tue, 18 Jun 2019 08:55:23 -0700 relnotes: document template support for `hg root`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 08:55:23 -0700] rev 42498
relnotes: document template support for `hg root` Differential Revision: https://phab.mercurial-scm.org/D6540
Tue, 18 Jun 2019 09:57:06 -0400 remotefilelog: tell runbgcommand to not block on child process startup
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:57:06 -0400] rev 42497
remotefilelog: tell runbgcommand to not block on child process startup These two invocations will always find a binary because they're re-running hg. As a result, we can skip waiting for the subprocess to start running and save a little bit of wall-time. Differential Revision: https://phab.mercurial-scm.org/D6539
Tue, 18 Jun 2019 09:43:27 -0400 procutil: allow callers of runbgcommand to assume the process starts
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:43:27 -0400] rev 42496
procutil: allow callers of runbgcommand to assume the process starts Experimentally starting the subprocess can take as much as 40ms, and for some of our use cases that's frivolous: we know the binary will start, and if it doesn't we'd only ever ignore it and continue anyway. This lets those use cases be faster. Differential Revision: https://phab.mercurial-scm.org/D6537
Tue, 18 Jun 2019 09:58:01 -0400 shallowrepo: remove backwards compat code that predates in-tree remotefilelog
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:58:01 -0400] rev 42495
shallowrepo: remove backwards compat code that predates in-tree remotefilelog Differential Revision: https://phab.mercurial-scm.org/D6538
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 tip