Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 01:48:10 -0400] rev 43125
perf: document `perfdirstatefoldmap`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 02:08:41 -0400] rev 43124
perf: use `setup` function in `perfdirstatedirs`
The command seems to pre-date the introduction of the `setup` support in timer.
We move the line that is obviously about benchmark setup in such `setup`
function.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 01:47:35 -0400] rev 43123
perf: document `perfdirstatedirs`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 01:57:10 -0400] rev 43122
perf: use `setup` function in `perfdirstate`
The command seems to pre-date the introduction of the `setup` support in timer.
We move the line that is obviously about benchmark setup in such `setup`
function.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 01:46:57 -0400] rev 43121
perf: document `perfdirstate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Oct 2019 01:15:28 -0400] rev 43120
perf: document `perfstatus`
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 09 Oct 2019 15:24:14 +0200] rev 43119
py3: flush ui after each message in interactive patch filtering
Otherwise, actions from ui.write() are buffered and displayed at end of
interactive session.
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 09 Oct 2019 15:28:16 +0200] rev 43118
py3: decode prompt string before calling rawinput
Calling input() (aka pycompat.rawinput() on python3) with a byte string
displays a byte string in the console. E.g. in interactive commit, we
get: b"examine changes to '<file>'?\n(enter ? for help) [Ynesfdaq?]".
Similarly, "hg email" prompts are messed up.
We thus decode the prompt string before running rawinput().
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Oct 2019 15:06:18 -0700] rev 43117
cleanup: join string literals that are already on one line
Thanks to Kyle for noticing this and for providing the regular
expression to run on the codebase.
This patch has been reviewed by the test suite and they approved of
it.
# skip-blame: fallout from mass reformatting
Differential Revision: https://phab.mercurial-scm.org/D7028
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Oct 2019 15:15:37 -0700] rev 43116
debugcommands: add a few more writenoi18n()
Differential Revision: https://phab.mercurial-scm.org/D7027
Martin von Zweigbergk <martinvonz@google.com> [Sun, 06 Oct 2019 20:17:41 -0700] rev 43115
py3: delete b'' prefix from safehasattr arguments
Differential Revision: https://phab.mercurial-scm.org/D7029
Kyle Lippincott <spectral@google.com> [Tue, 08 Oct 2019 19:35:30 -0700] rev 43114
destutil: provide hint on rebase+merge for how to specify destination/rev
Without a destination specified, rebase and merge attempt to identify a good
candidate; this fails if there's too many heads, the heads have a bookmark, or
other reasons.
Complicating the issue, users may have specified -t, thinking it means target,
and are confused when the error message says that they need to specify an
explicit rev or explicit destination - they feel like they already have.
Differential Revision: https://phab.mercurial-scm.org/D7024
Kyle Lippincott <spectral@google.com> [Tue, 08 Oct 2019 10:40:36 -0700] rev 43113
hghave: document format for version feature checks as <name><vers>, no dots
I had a bit of a difficult time when attempting to fix a use of `py-38` when
trying to figure out what the correct way of specifying the feature was. By
having the strings 'py-3*' and 'py3.8' in the hghave.checkvers docstring, I
would have had a much easier time of it instead of having to trace exactly what
was happening here.
Differential Revision: https://phab.mercurial-scm.org/D7023
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 02 Feb 2018 10:13:42 -0800] rev 43112
check-commit: allow foo_bar naming in functions
nameswithallthewordssmashedtogetherarehardtoread.
especiallyifenglishisnotyourprimarylanguage.
Let's align with the rest of the programming universe and
allow_the_use_of_underscores_in_names.
We took a hand poll at the 5.2 sprint regarding this change and
all but 1 person supported it. The person who didn't expressed
concerns around excessive API breakage if we mass renamed things.
But we're not planning to mass rename things for the sake of
renaming, so all should be well.
Differential Revision: https://phab.mercurial-scm.org/D2010