Fri, 15 Nov 2019 11:30:33 -0500 extensions: suppress a pytype failure due to a typeshed bug
Augie Fackler <augie@google.com> [Fri, 15 Nov 2019 11:30:33 -0500] rev 43747
extensions: suppress a pytype failure due to a typeshed bug Bug filed upstream, suppress the failure here so we can move on. Differential Revision: https://phab.mercurial-scm.org/D7410
Thu, 14 Nov 2019 15:49:21 -0500 dispatch: add some assertions to give pytype a helping hand
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:21 -0500] rev 43746
dispatch: add some assertions to give pytype a helping hand Differential Revision: https://phab.mercurial-scm.org/D7409
Thu, 14 Nov 2019 15:49:01 -0500 extensions: hide two confusing import statements from pytype
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:49:01 -0500] rev 43745
extensions: hide two confusing import statements from pytype Differential Revision: https://phab.mercurial-scm.org/D7408
Thu, 14 Nov 2019 13:27:57 -0500 debugcommands: add assertions to convince pytype peer is not None
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 13:27:57 -0500] rev 43744
debugcommands: add assertions to convince pytype peer is not None This function is moderately annoyingly defined, and peer is set up iff we're not in raw-proto mode. That's fine, but it confuses pytype. Adding these assertions is a low-overhead way to convince pytype we're doing reasonable things. Differential Revision: https://phab.mercurial-scm.org/D7407
Wed, 13 Nov 2019 22:35:15 -0500 debugcommands: suppress import errors for pytype
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:35:15 -0500] rev 43743
debugcommands: suppress import errors for pytype Differential Revision: https://phab.mercurial-scm.org/D7385
Wed, 13 Nov 2019 22:22:49 -0500 state: add a pytype annotation
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:22:49 -0500] rev 43742
state: add a pytype annotation Differential Revision: https://phab.mercurial-scm.org/D7383
Wed, 13 Nov 2019 22:22:31 -0500 logcmdutil: add a type annotation
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:22:31 -0500] rev 43741
logcmdutil: add a type annotation This wasn't actually required in the end, as there was a real bug found by pytype, but the annotation helped me figure that out. We can drop this patch if that's the preference. Differential Revision: https://phab.mercurial-scm.org/D7382
Wed, 13 Nov 2019 22:21:38 -0500 cmdutil: add a pytype annotation to help out some callsites
Augie Fackler <augie@google.com> [Wed, 13 Nov 2019 22:21:38 -0500] rev 43740
cmdutil: add a pytype annotation to help out some callsites I think we could constrain the values here more than Any, but this lets us move forward with typechecking commands.py. Differential Revision: https://phab.mercurial-scm.org/D7381
Tue, 12 Nov 2019 17:47:42 -0500 hghave: add a check for the `xz` compression utility
Matt Harbison <matt_harbison@yahoo.com> [Tue, 12 Nov 2019 17:47:42 -0500] rev 43739
hghave: add a check for the `xz` compression utility This isn't install by default on Mac, which causes a test failure. The logic for avoiding the command is a little goofy, but nested `#if` isn't supported, and it still seems worth running the hg command to see if anything explodes. With this, the py3 tests run (almost) cleanly on 10.14.6: # Ran 835 tests, 58 skipped, 1 failed. Alas, the mac-packaging test is skipped because it's slow. The failure here is in test-releasenotes-merging.t, complaining about not being able to import the `fuzzywuzzy` module. I have it installed on py3 (thus the test isn't skipped), but not on py2. So there must be some unintended cross pollination here when running `hg` commands. Differential Revision: https://phab.mercurial-scm.org/D7374
Thu, 14 Nov 2019 22:31:21 -0800 py3: use '%d' for formatting a revnum in `hg co --date` code
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 22:31:21 -0800] rev 43738
py3: use '%d' for formatting a revnum in `hg co --date` code Differential Revision: https://phab.mercurial-scm.org/D7429
Mon, 18 Nov 2019 17:37:59 +0100 py3: send bytes from Rust-created warning patterns
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:37:59 +0100] rev 43737
py3: send bytes from Rust-created warning patterns Python code expects bytes in both Python 2 and Python 3, so we should send bytes. Differential Revision: https://phab.mercurial-scm.org/D7454
Mon, 18 Nov 2019 17:34:44 +0100 py3: pass bytes to `configint` and `configbool`
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Nov 2019 17:34:44 +0100] rev 43736
py3: pass bytes to `configint` and `configbool` Both functions require bytes, even in Python 3. Differential Revision: https://phab.mercurial-scm.org/D7453
Fri, 15 Nov 2019 10:16:27 -0800 templates: make {indent("", " ")} be empty
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 10:16:27 -0800] rev 43735
templates: make {indent("", " ")} be empty indent() is documented to indent all non-empty lines, but it made an exception for the first line, which always got indented. I also made indent() not indent the first line even if an indent override was given for the first line. I think that is what one would usually want. Differential Revision: https://phab.mercurial-scm.org/D7432
Fri, 15 Nov 2019 10:16:22 -0800 tests: document behavior of indent() with empty first line
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Nov 2019 10:16:22 -0800] rev 43734
tests: document behavior of indent() with empty first line indent() is documented to indent all non-empty lines, but it still indents the first line even if it's empty. Let's have tests for that. Differential Revision: https://phab.mercurial-scm.org/D7431
Sat, 16 Nov 2019 12:08:02 -0800 tests: check for Windows line endings
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 16 Nov 2019 12:08:02 -0800] rev 43733
tests: check for Windows line endings We shouldn't generally be using Windows line endings in files under version control. I've accidentally committed a few files with Windows line endings recently. So let's add a test for this. Differential Revision: https://phab.mercurial-scm.org/D7448
Sat, 16 Nov 2019 11:54:39 -0800 tests: verify that Python scripts are blackened
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 16 Nov 2019 11:54:39 -0800] rev 43732
tests: verify that Python scripts are blackened Scripts are Python too. They should be blackened. (As suggested by Pierre-Yves in D7420.) Differential Revision: https://phab.mercurial-scm.org/D7447
Sat, 16 Nov 2019 11:53:47 -0800 black: blacken scripts
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 16 Nov 2019 11:53:47 -0800] rev 43731
black: blacken scripts These scripts weren't blackened. I found these as part of adding script checking to test-check-format.t. # skip-blame black Differential Revision: https://phab.mercurial-scm.org/D7446
Sat, 16 Nov 2019 11:59:22 -0800 doc: don't use mutable default arguments
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 16 Nov 2019 11:59:22 -0800] rev 43730
doc: don't use mutable default arguments It appears our mutable default arguments checker doesn't find arguments not on the first line of a function definition :( The arguments aren't used, so the default value is irrelevant. I found this when blackening this script in a future commit. Differential Revision: https://phab.mercurial-scm.org/D7445
Thu, 14 Nov 2019 21:58:36 -0800 tags: don't check for clean files when checking for dirty working copy
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 21:58:36 -0800] rev 43729
tags: don't check for clean files when checking for dirty working copy We didn't request status for clean files so there should never be any entries in the list of clean files (at least not since dd773340a085), but it's misleading to check the list. Differential Revision: https://phab.mercurial-scm.org/D7428
Thu, 14 Nov 2019 21:13:46 -0800 branchmap: make "closed" a set from beginning instead of converting from list
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 21:13:46 -0800] rev 43728
branchmap: make "closed" a set from beginning instead of converting from list Differential Revision: https://phab.mercurial-scm.org/D7427
Sun, 17 Nov 2019 01:34:52 -0500 debugextensions: gracefully handle missing __file__ attributes
Matt Harbison <matt_harbison@yahoo.com> [Sun, 17 Nov 2019 01:34:52 -0500] rev 43727
debugextensions: gracefully handle missing __file__ attributes This was crashing PyOxidizer. Differential Revision: https://phab.mercurial-scm.org/D7452
Sun, 17 Nov 2019 01:00:06 -0500 debuginstall: gracefully handle missing __file__ attributes
Matt Harbison <matt_harbison@yahoo.com> [Sun, 17 Nov 2019 01:00:06 -0500] rev 43726
debuginstall: gracefully handle missing __file__ attributes This was crashing PyOxidizer. While here, point "Python lib" and "installed modules" to the oxidized binary when read from memory instead of pretending their location is unknown. Differential Revision: https://phab.mercurial-scm.org/D7451
Sat, 16 Nov 2019 16:25:28 +0900 typing: add pseudo localstr.__init__() to help pytype
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 16:25:28 +0900] rev 43725
typing: add pseudo localstr.__init__() to help pytype Apparently, pytype failed to parse localstr.__new__()? This fixes the following errors: line 126, in __hash__: No attribute '_utf8' on localstr [attribute-error] line 188, in tolocal: Function localstr.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, string: str, ...) Actually passed: (self, string: bytes, ...)
Sat, 16 Nov 2019 15:24:49 +0900 typing: fix argument type of encoding.localstr()
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:24:49 +0900] rev 43724
typing: fix argument type of encoding.localstr() It takes both utf-8 and local strings in bytes type.
Sat, 16 Nov 2019 16:09:39 +0900 typing: suppress error of py2 encoding.strtolocal() and .strfromlocal()
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 16:09:39 +0900] rev 43723
typing: suppress error of py2 encoding.strtolocal() and .strfromlocal() I don't know how to conditionally get rid of these py2/py3 overloads from .pyi file. Instead, this patch makes pytype ignore the false-positives: line 271, in strtolocal: bad option in return type [bad-return-type] Expected: bytes Actually returned: str
Sat, 16 Nov 2019 15:34:47 +0900 typing: constrain argument/return types of encoding.toutf8b()
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:34:47 +0900] rev 43722
typing: constrain argument/return types of encoding.toutf8b()
Sat, 16 Nov 2019 15:27:12 +0900 typing: fix argument type of encoding.tolocal() and .fromutf8b()
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:27:12 +0900] rev 43721
typing: fix argument type of encoding.tolocal() and .fromutf8b() Fixes various pytype errors.
Sat, 16 Nov 2019 15:10:41 +0900 typing: fix forward reference in _Tlocalstr type bound
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:10:41 +0900] rev 43720
typing: fix forward reference in _Tlocalstr type bound AFAIK, a quoted string in type position is translated to its ForwardRef. https://github.com/python/typing/issues/34 This fixes the following error: File "mercurial/encoding.py", line 38, in <module>: Name 'localstr' is not defined [name-error]
Sat, 16 Nov 2019 15:43:21 +0900 encoding: make getcols() raise exception explicitly
Yuya Nishihara <yuya@tcha.org> [Sat, 16 Nov 2019 15:43:21 +0900] rev 43719
encoding: make getcols() raise exception explicitly This helps pytype. File "mercurial/encoding.py", line 329, in getcols: bad option in return type [bad-return-type] Expected: bytes Actually returned: None
Sat, 16 Nov 2019 12:19:43 -0500 setup: conditionalize access to `sys.dllhandle` when building extensions
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 12:19:43 -0500] rev 43718
setup: conditionalize access to `sys.dllhandle` when building extensions This code is only run on Windows, and was crashing PyOxidizer when running in `setup-py-install` mode. Now an oxidized binary can be built by simply pointing to setup.py. Something is slightly different now that it's not being built from a virtualenv. Previously, `hg version` could print to the screen, but now it aborts saying "Incorrect function". But I can see the output if redirected to a file, and it's not complaining about missing C extensions, so I think those are loading now (unlike from the virtualenv). The interesting this about this incorrect function output is that it failed when initially built. I then went back and did a `make clean` and `make local` with py3 and then py2 to ensure I didn't break the existing code. At that point I ran the oxidized executable again and it was able to print to the screen normally! So I ran `pyoxidizer build` again, it only output the following, and then running the executable failed to output again: (pyO2_venv) C:\Users\Matt\hg3\hg_pyO2>pyoxidizer build Finished dev [unoptimized + debuginfo] target(s) in 0.12s packaging application into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug purging C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug copying C:/Users/Matt/hg3/hg_pyO2\build\target\x86_64-pc-windows-msvc\debug\hg_pyO2.exe to C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe resolving packaging state... writing license for [...] hg_pyO2 packaged into C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug executable path: C:/Users/Matt/hg3/hg_pyO2\build\apps\hg_pyO2\x86_64-pc-windows-msvc\debug\hg_pyO2.exe Differential Revision: https://phab.mercurial-scm.org/D7444
Sat, 16 Nov 2019 11:48:47 -0500 setup: use bytes for assumed python version
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 11:48:47 -0500] rev 43717
setup: use bytes for assumed python version Caught by PyOxidizer when hacking on Windows. # skip-blame for b'' prefixing Differential Revision: https://phab.mercurial-scm.org/D7443
Sat, 16 Nov 2019 11:42:27 -0500 setup: combine two contiguous string literals
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Nov 2019 11:42:27 -0500] rev 43716
setup: combine two contiguous string literals Differential Revision: https://phab.mercurial-scm.org/D7442
Thu, 14 Nov 2019 13:18:22 -0800 util: remove datapath and swith users over to resourceutil
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 13:18:22 -0800] rev 43715
util: remove datapath and swith users over to resourceutil The util module no longer needs the datapath for injecting it into the i18n module, so we can remove it from there and update other users. Differential Revision: https://phab.mercurial-scm.org/D7436
Thu, 14 Nov 2019 12:41:33 -0800 i18n: get datapath directly from resourceutil
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 12:41:33 -0800] rev 43714
i18n: get datapath directly from resourceutil The new resourceutil module is lower in the dependency graph, so we can depend directly on it and won't have to depend on the util module to inject the datapath. Differential Revision: https://phab.mercurial-scm.org/D7435
Thu, 14 Nov 2019 12:33:10 -0800 util: move definition of datapath to resourceutil
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Nov 2019 12:33:10 -0800] rev 43713
util: move definition of datapath to resourceutil Since this means moving the function into a subdirectory, we have to compensate by adding another layer of os.path.dirname(). Differential Revision: https://phab.mercurial-scm.org/D7434
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
Thu, 14 Nov 2019 15:26:17 -0500 cmdutil: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:26:17 -0500] rev 43688
cmdutil: 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/D7396
Thu, 14 Nov 2019 15:26:05 -0500 uncommit: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:26:05 -0500] rev 43687
uncommit: 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/D7395
Thu, 14 Nov 2019 15:25:57 -0500 transplant: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:25:57 -0500] rev 43686
transplant: 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/D7394
Thu, 14 Nov 2019 15:25:48 -0500 split: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:25:48 -0500] rev 43685
split: 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/D7393
Thu, 14 Nov 2019 15:25:40 -0500 mq: use field names instead of field numbers on scmutil.status
Augie Fackler <augie@google.com> [Thu, 14 Nov 2019 15:25:40 -0500] rev 43684
mq: 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/D7392
(0) -30000 -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 +3000 tip