Augie Fackler <augie@google.com> [Sun, 04 Mar 2018 16:23:03 -0500] rev 36995
tests: stop over-specifying tempfile name
Python 3 has more random characters in the default template, which is fine.
Differential Revision: https://phab.mercurial-scm.org/D2676
Matt Harbison <matt_harbison@yahoo.com> [Sat, 10 Mar 2018 23:58:01 -0500] rev 36994
wireproto: explicitly flush stdio to prevent stalls on Windows
This is the key to fixing the hangs on Windows in D2720[1]. I put flushes in a
bunch of other places that didn't help, but I suspect that's more a lack of test
coverage than anything else.
Chasing down stuff like this is pretty painful. I'm wondering if we can put a
proxy around sys.stderr (and sys.stdout?) on Windows (only when daemonized?)
that will flush on every write (or at least every write with a '\n').
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-March/113352.html
Matt Harbison <matt_harbison@yahoo.com> [Sun, 18 Mar 2018 15:32:49 -0400] rev 36993
test-lfs: glob over some output changes
These changes started with 2090044a288d. They aren't important to LFS testing.
Yuya Nishihara <yuya@tcha.org> [Fri, 16 Mar 2018 21:24:12 +0900] rev 36992
templater: factor out helper that renders named template as string
This is quite common in non-web templating, and **kwargs expansion is annoying
because of the unicode-ness of Python3.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 11:23:04 +0900] rev 36991
templater: rename .render(mapping) to .renderdefault(mapping) (API)
I'm going to add templ.render(t, mapping) and templ.generate(t, mapping) in
place of stringify(templ(t, **mapping)) and templ(t, **mapping) respectively.
.. api::
The ``render(mapping)`` method of the templater has been renamed to
``renderdefault(mapping)``.
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 15:22:14 +0900] rev 36990
templater: fix invalid reference of runsymbol in doctest
Oversight at da710c3df4dc. I was just lucky that this lambda function is
never evaluated.
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Mar 2018 12:54:03 +0900] rev 36989
cmdutil: drop redundant import of merge module
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:36:28 +0900] rev 36988
annotate: add support for template keywords and functions depending on ctx
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:26:15 +0900] rev 36987
formatter: unblock storing fctx as a template resource
To keep templateformatter._renderitem() simple, a repo instance is looked
through ctx if available. This is probably good for future subrepo support
where ctx.repo() may be different from the global repo.
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:12:02 +0900] rev 36986
templater: process mapping dict by resource callables
A resource item is a callable, so let's make it look up a resource object
by itself.
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Mar 2018 21:05:29 +0900] rev 36985
templater: convert resources to a table of callables for future extension
I'm going to add a full templating support to the annotate command. As the
annotate is a filectx-oriented command, we'll need a way to look up a ctx
from a bounded fctx only when necessary.
This is the minimal change to support that. I'm thinking of defining a proper
interface to look up template resources to fix other issues, but that isn't
ready yet.
(Changes from V1: just updated tests and patch descriptions.)
Augie Fackler <augie@google.com> [Sat, 17 Mar 2018 21:46:17 -0400] rev 36984
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 16 Mar 2018 12:10:15 -0700] rev 36983
hgweb: convert an assert to a ProgrammingError
Because assert may get optimized away.
Differential Revision: https://phab.mercurial-scm.org/D2882
Kyle Lippincott <spectral@google.com> [Fri, 19 Jan 2018 18:52:50 -0800] rev 36982
filemerge: give some variables in _xmerge more descriptive names
Differential Revision: https://phab.mercurial-scm.org/D2886
Martin von Zweigbergk <martinvonz@google.com> [Thu, 15 Mar 2018 13:19:55 -0700] rev 36981
rebase: allow in-memory merge of the working copy parent
Before this patch and when the rebase involved the working copy parent
(and thus the working copy too), we would not do in-memory rebase even
if requested to. The in-code comment explains that the reason had
something to do with avoiding an extra update, but I don't know which
update that refers to. Perhaps an earlier version of the code used to
update to the destination before rebasing even if in-memory rebase was
requested? That seems to not be done at least since aa660c1203a9
(rebase: do not bail on uncomitted changes if rebasing in-memory,
2017-12-07).
To see if this still made it slower, I create a single tiny commit on
top of one branch of the mozilla-unified repo (commit a1098c82 to be
exact) and rebased it to another branch (commit d4e9a7be). Before this
patch that took 11.8s and after this patch it took 8.6s (I only did
two runs each, but the timings were very consistent).
Differential Revision: https://phab.mercurial-scm.org/D2876
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Mar 2018 09:33:17 -0700] rev 36980
uncommit: simplify condition for keeping commit
We used to keep the commit if it would have become empty and --keep
was not passed. Since we just changed it so we also keep it if any
patterns were passed on the command line, the only remaining case
where we prune the commit is when no arguments were passed and --keep
was not passed either, we can simplify the "not files and not
allowempty" to just "not allowempty". Let's also rename "allowempty"
to "keepcommit" since it's no longer about allowing an empty commit.
Differential Revision: https://phab.mercurial-scm.org/D2891
Martin von Zweigbergk <martinvonz@google.com> [Sat, 17 Mar 2018 09:49:21 -0700] rev 36979
uncommit: document when the commit will be pruned
Differential Revision: https://phab.mercurial-scm.org/D2890
Martin von Zweigbergk <martinvonz@google.com> [Wed, 14 Mar 2018 11:16:49 -0700] rev 36978
uncommit: leave empty commit if all files are uncommitted
We had instructions for our internal users to add copy information
after commit like this:
hg uncommit <srcfile> <dstfile>
hg cp --after <srcfile> <dstfile>
hg amend
That usually works, but if the rename was the only change in that
commit, then the commit would get pruned. It's easy to fix the recipe:
just pass the --keep option. However, it seems too subtle, so I think
this is an indication that the commit should not be pruned if any
patterns were given.
Differential Revision: https://phab.mercurial-scm.org/D2862
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Mar 2018 00:06:14 +0900] rev 36977
test-template-engine: do not evaluate unused keywords by custom engine
If the custom engine, "mytemplater", were installed as the default, it would
enter to an infinite recursion at stringify(v) because template keywords may
generate a nested mapping containing the same keywords.
Spotted by a future patch which will replace context.resource('templ')(...)
with context.process(...).
Yuya Nishihara <yuya@tcha.org> [Fri, 16 Mar 2018 23:59:13 +0900] rev 36976
py3: make test-template-engine.t bytes-safe
Yuya Nishihara <yuya@tcha.org> [Thu, 15 Mar 2018 20:10:54 +0900] rev 36975
test-template-engine: deduplicate methods of custom template engine
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 15:10:22 +0100] rev 36974
revbranchcache: advertise and use 'rbc' exchange capability
The feature is now advertised and use.
Updating the branchmap cache can be very expensive (up to minutes on large
repository) and fetching revision branch data is about 80% of that. Exchanging
the rev branch cache over the wire really help to recover from branch map
invalidation.
(There is a good chance other in flight chance would conflict on
test-http-bad-server.t and other. So here is a small note to help update that
test again: capabilities=19bytes, part-107bytes)
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 19:26:41 +0100] rev 36973
revbranchcache: disable the new part for narrow hg bundle
The lack of some revisions confuses the new cache part. To simplify things, we
disable it for now.
Boris Feld <boris.feld@octobus.net> [Thu, 18 Jan 2018 14:58:02 +0100] rev 36972
revbranchcache: add the necessary bit to send 'rbc' data over bundle2
Getbundle is now capable of sending rev-branch-cache information for the
changesets it bundle. The data sent are mostly nodes so it is quite compact.
The goal of the rev-branch-cache is to speed up branch map computation,
especially when the branchmap gets invalidated so we send data for all
exchanged changesets. In addition, computing the relevant heads to send in
case of partial pulling would be challenging.
The feature is still inactive since the capability is not advertised yet.