Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:19:32 -0700] rev 42504
log: pass getcopies() function instead of getrenamed() to displayer (API)
This reduces the duplication between the two displayer functions (and
between them and scmutil.getcopiesfn()). It's still more code than two
patches ago, but there's less duplication.
Differential Revision: https://phab.mercurial-scm.org/D6546
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 09:59:45 -0700] rev 42503
copies: create helper for getting all copies for changeset
There are a few places where we get all the copies for a changeset (at
least the {file_copies} template and in two places in `hg log
--copies` code). These places currently call scmutil.getrenamedfn() to
get a caching "getrenamed" function. They all use it in a similar
way. We will be able to reuse more code by having a function for
getting all the copies for a changeset. This patch introduces such a
function. It uses it in the {file_copies} template to show that it
works. It relies on the existing scmutil.getrenamedfn() for caching in
the filelog-centric case.
Differential Revision: https://phab.mercurial-scm.org/D6545
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:19:24 -0700] rev 42502
logcmdutil: also check for copies in null revision and working copy
It's safe (and fast) to look for copies in the null revision, and it's
incorrect not to look for them in the working copy, so let's look in
both places.
Differential Revision: https://phab.mercurial-scm.org/D6544
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
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
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
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
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
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
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