Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:27:09 -0400] rev 43662
histeditrule: split __bytes__ property into prefix and desc
In order to be able to colourise the description of the rule, we need
to have it as a separate bytestring. Curses doesn't make it easy to
take existing text on the screen and give it different properties; we
can only add new text with new properties.
Yuya Nishihara <yuya@tcha.org> [Fri, 15 Nov 2019 22:22:55 +0900] rev 43661
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:40:54 -0800] rev 43660
packaging: convert to UNIX line endings
I must have my editor on Windows configured incorrectly because
I submitted patches with Windows line endings :(
# skip-blame whitespace only line ending changes
Differential Revision: https://phab.mercurial-scm.org/D7421
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:35:11 -0800] rev 43659
black: blacken scripts
test-check-format.t doesn't appear to detect Python scripts with shebangs.
But my editor which is configured to auto run black on Python files does
and it appears some files are not blackened.
This commit blackens scripts that need it.
# skip-blame reformatting
Differential Revision: https://phab.mercurial-scm.org/D7420
Augie Fackler <augie@google.com> [Tue, 12 Nov 2019 10:17:59 -0500] rev 43658
dirs: resolve fuzzer OOM situation by disallowing deep directory hierarchies
It seems like 2048 directories ought to be enough for any reasonable
use of Mercurial?
A previous version of this patch scanned for slashes before any allocations
occurred. That approach is slower than this in the happy path, but much faster
than this in the case that too many slashes are encountered. We may want to
revisit it in the future using memchr() so it'll be well-optimized by the libc
we're using.
.. bc:
Mercurial will now defend against OOMs by refusing to operate on
paths with 2048 or more components. This means that _extremely_
deep path hierarchies will be rejected, but we anticipate nobody
is using hierarchies this deep.
Differential Revision: https://phab.mercurial-scm.org/D7411
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:14:11 -0800] rev 43657
py3: use native string for 'macosx_app'
I couldn't find any definitive information on this, but all examples
(except for ours) seem to use a native string.
Differential Revision: https://phab.mercurial-scm.org/D7414
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:07:36 -0800] rev 43656
py3: drop an unnecessary fsencode() before comparing with constant
Differential Revision: https://phab.mercurial-scm.org/D7413
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:03:02 -0800] rev 43655
py3: use native string as fallback value for __file__ for consistency
This is not a bugfix (pycommpat.fsencode(b'') is a no-op on py3), but
the b'' value was inconsistent and confusing.
Differential Revision: https://phab.mercurial-scm.org/D7412
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 13:38:17 -0500] rev 43654
scmutil: convert status data object from a tuple to an attrs (API)
We've been pushing towards the property names for a while, and the
subclassing of the tuple confuses pytype. Rather than bend over
backwards to try and annotate the tuple subclass, let's just use attrs
here.
Differential Revision: https://phab.mercurial-scm.org/D7406
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:29:27 -0500] rev 43653
perf: bool() elements of dirstate.status return instead of len()
I'm about to make scmutil.status no longer have a len(), so we need to do
something else to "use" the results in this perf method.
Differential Revision: https://phab.mercurial-scm.org/D7405