Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 14:02:01 +0200] rev 42402
perf: factor selection of revisions involved in the merge out
We will introduce more performance command around merge. As a first step we
factor out pieces of `perfmergecalculate` that can be reused.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 13:49:31 +0200] rev 42401
perf: allow to specify the base of the merge in perfmergecalculate
We can now test the rebase case.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 11:19:48 +0200] rev 42400
perf: add a --from flag to perfmergecalculate
Before this change, `perfmergecalculate` was always benchmarking the merge of
the working copy with another revision. We can now benchmark the
`mergecalculate` call for any arbitrary pair of revision.
Augie Fackler <augie@google.com> [Tue, 28 May 2019 09:57:53 -0400] rev 42399
merge with stable
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 25 May 2019 19:49:44 +0300] rev 42398
py3: fix test-narrow* which started failing because of recent changes
#skip-blame because just r'' prefix
Differential Revision: https://phab.mercurial-scm.org/D6447
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:06:06 -0700] rev 42397
tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit
Differential Revision: https://phab.mercurial-scm.org/D6368
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 13:34:20 -0700] rev 42396
context: add ctx.files{modified,added,removed}() methods
Changeset-centric copy tracing is currently very slow because it often
reads manifests. One place it needs the manifest is in _chain(), where
it removes a copy X->Y if Y has subsequently gotten removed. I want to
speed that up by keeping track directly in the changeset of which
files are removed in the changeset. These methods will be similar to
ctx.p[12]copies() in that way: they will either read from the
changeset or calculate the information from the manifests otherwise.
Note that these are different from ctx.{modified,added,removed}() on
merge commits. Those functions always compare to p1, but the new ones
compare to both parents. filesadded() means "file does not exist in
either parent but exists now", filesremoved() means "file existed in
either parent but does not exist now", and filesmodified() means "file
existed in either parent and still exists". The set of files in
ctx.files() is the union of the files from the three new functions
(and the three new ones are all disjoint sets).
Also note that uncommitted merges are weird as usual. The invariant
mentioned above still holds, but the functions compare to p1 (and are
thus identical to the existing methods).
Differential Revision: https://phab.mercurial-scm.org/D6367
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 May 2019 15:09:07 -0700] rev 42395
copies: split up _chain() in naive chaining and filtering steps
The function now has two clearly defined steps. The first step is the
actual chaining. This step is very cheap. The second step is filtering
out invalid copies. This step is expensive. For changeset-centric copy
tracing, I want to do the filtering step only at the end. This patch
prepares for that.
Differential Revision: https://phab.mercurial-scm.org/D6418
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 May 2019 09:24:47 -0700] rev 42394
relnotes: document changed behavior of ui.origbackuppath pointing to file
Differential Revision: https://phab.mercurial-scm.org/D6446
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:17:42 -0700] rev 42393
templatekw: move showfileadds() close to showfile{mods,dels}()
Differential Revision: https://phab.mercurial-scm.org/D6370