Thu, 14 Nov 2019 11:52:22 -0800 procutil: move mainfrozen() to new resourceutil.py
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 11:52:22 -0800] rev 43712
procutil: move mainfrozen() to new resourceutil.py The i18n module practically depends on procutil for mainfrozen() but since procutil depends on i18n, it would be a circular dependency if i18n depended directly on procutil. The cycle is currently resolved by having the higher-level util module calculate the "datapath" and inject it into i18n. Extracting mainfrozen() to a new module lets us clean up the dependencies. Differential Revision: https://phab.mercurial-scm.org/D7433
Thu, 14 Nov 2019 17:36:01 -0800 defaults: rename default.d to defaultrc to make it a valid package name
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 17:36:01 -0800] rev 43711
defaults: rename default.d to defaultrc to make it a valid package name "default.d" is not a valid Python package name, and it needs to be a valid package name if we want to be able to load the files from here as resources. Differential Revision: https://phab.mercurial-scm.org/D7426
Thu, 14 Nov 2019 17:30:52 -0800 help: remove references to default.d/ from user-facing docs
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 17:30:52 -0800] rev 43710
help: remove references to default.d/ from user-facing docs The user doesn't need to know what we call the internal directory and I'm about to rename it. Differential Revision: https://phab.mercurial-scm.org/D7425
Thu, 14 Nov 2019 10:47:04 +0100 bisect: replace try:/finally: by a "restore_state" context manager
Denis Laxalde <denis.laxalde@logilab.fr> [Thu, 14 Nov 2019 10:47:04 +0100] rev 43709
bisect: replace try:/finally: by a "restore_state" context manager This should help pytype to not consider "bgood" variable as NameError. See https://phab.mercurial-scm.org/D7384 for context. Differential Revision: https://phab.mercurial-scm.org/D7430
Wed, 30 Oct 2019 19:19:57 -0400 histedit: render a rolled up description using the proper roll colours
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:19:57 -0400] rev 43708
histedit: render a rolled up description using the proper roll colours Users have rightfully complained that the old behaviour of completely removing the description of a rolled commit makes it difficult to remember what was in that commit. Instead, we now render the removed description in red. I couldn't think of a simpler way to do this. You can't just combine existing curses colours into new effects; only secondary effects like bold or underline can be logically OR'ed to generate a combined text effect. It seems easier to just redundantly keep track of what the roll colour should be.
Wed, 30 Oct 2019 19:34:57 -0400 histedit: define new colour pairs for roll action
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:34:57 -0400] rev 43707
histedit: define new colour pairs for roll action Red seems like a good colour to indicate removal, since that's the colour we use in diffs. We need three varieties with three different backgrounds corresponding to the possible ways we can display a rule.
Wed, 30 Oct 2019 19:27:09 -0400 histeditrule: split __bytes__ property into prefix and desc
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 30 Oct 2019 19:27:09 -0400] rev 43706
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.
Fri, 15 Nov 2019 22:22:55 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Fri, 15 Nov 2019 22:22:55 +0900] rev 43705
merge with stable
Thu, 14 Nov 2019 20:40:54 -0800 packaging: convert to UNIX line endings
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:40:54 -0800] rev 43704
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
Thu, 14 Nov 2019 20:35:11 -0800 black: blacken scripts
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Nov 2019 20:35:11 -0800] rev 43703
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
Tue, 12 Nov 2019 10:17:59 -0500 dirs: resolve fuzzer OOM situation by disallowing deep directory hierarchies
Augie Fackler <augie@google.com> [Tue, 12 Nov 2019 10:17:59 -0500] rev 43702
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
Thu, 14 Nov 2019 14:14:11 -0800 py3: use native string for 'macosx_app'
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:14:11 -0800] rev 43701
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
Thu, 14 Nov 2019 14:07:36 -0800 py3: drop an unnecessary fsencode() before comparing with constant
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:07:36 -0800] rev 43700
py3: drop an unnecessary fsencode() before comparing with constant Differential Revision: https://phab.mercurial-scm.org/D7413
Thu, 14 Nov 2019 14:03:02 -0800 py3: use native string as fallback value for __file__ for consistency
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 14:03:02 -0800] rev 43699
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
Thu, 14 Nov 2019 13:38:17 -0500 scmutil: convert status data object from a tuple to an attrs (API)
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 13:38:17 -0500] rev 43698
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
Thu, 14 Nov 2019 15:29:27 -0500 perf: bool() elements of dirstate.status return instead of len()
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:29:27 -0500] rev 43697
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
Thu, 14 Nov 2019 15:28:44 -0500 tags: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:44 -0500] rev 43696
tags: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7404
Thu, 14 Nov 2019 15:28:34 -0500 subrepo: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:34 -0500] rev 43695
subrepo: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7403
Thu, 14 Nov 2019 15:28:08 -0500 revset: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:28:08 -0500] rev 43694
revset: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7402
Thu, 14 Nov 2019 15:27:58 -0500 patch: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:58 -0500] rev 43693
patch: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7401
Thu, 14 Nov 2019 15:27:50 -0500 logcmdutil: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:50 -0500] rev 43692
logcmdutil: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7400
Thu, 14 Nov 2019 15:27:40 -0500 context: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:40 -0500] rev 43691
context: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7399
Thu, 14 Nov 2019 15:27:32 -0500 commands: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:32 -0500] rev 43690
commands: use field names instead of field numbers on scmutil.status As part of my pytype adventures I want to make scmutil.status no longer a subclass of tuple. This is part of that process. Differential Revision: https://phab.mercurial-scm.org/D7398
Thu, 14 Nov 2019 15:27:20 -0500 cmdutil: convert terse status result back to an scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:27:20 -0500] rev 43689
cmdutil: convert terse status result back to an scmutil.status This is also part of detupling scmutil.status. Differential Revision: https://phab.mercurial-scm.org/D7397
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 tip