Tue, 08 Oct 2019 19:35:30 -0700 destutil: provide hint on rebase+merge for how to specify destination/rev
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
Tue, 08 Oct 2019 10:40:36 -0700 hghave: document format for version feature checks as <name><vers>, no dots
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
Fri, 02 Feb 2018 10:13:42 -0800 check-commit: allow foo_bar naming in functions
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
Tue, 08 Oct 2019 13:38:02 -0400 infinitepush: mark extension as likely to be deleted
Augie Fackler <augie@google.com> [Tue, 08 Oct 2019 13:38:02 -0400] rev 43111
infinitepush: mark extension as likely to be deleted .. bc:: The infinitepush extension is believed to be unused, and will be deleted at the end of 2020 unless users contact mercurial-devel@mercurial-scm.org. Differential Revision: https://phab.mercurial-scm.org/D7022
Mon, 07 Oct 2019 10:34:21 -0400 tests: use range() in generate-churning-module.py
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Oct 2019 10:34:21 -0400] rev 43110
tests: use range() in generate-churning-module.py This is a test-only script. Performance on Python 2 for creating a full list instead of a generator doesn't matter. With this change, test-check-pyflakes.t passes on Python 3! Differential Revision: https://phab.mercurial-scm.org/D7019
Mon, 07 Oct 2019 10:31:11 -0400 tests: allow warning about file
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Oct 2019 10:31:11 -0400] rev 43109
tests: allow warning about file The code is protected by a block that makes it Python 2 only, so use of file is acceptable. Differential Revision: https://phab.mercurial-scm.org/D7018
Mon, 07 Oct 2019 10:28:32 -0400 lsprof: remove __main__ functionality
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Oct 2019 10:28:32 -0400] rev 43108
lsprof: remove __main__ functionality I'm pretty sure nobody uses this. I noticed it because Python 3 linting is complaining about execfile. Differential Revision: https://phab.mercurial-scm.org/D7017
Mon, 07 Oct 2019 10:26:46 -0400 tests: use proper Python 3.8 feature
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Oct 2019 10:26:46 -0400] rev 43107
tests: use proper Python 3.8 feature Fix typo introduced in 830eacef67f8. Differential Revision: https://phab.mercurial-scm.org/D7016
Mon, 07 Oct 2019 00:04:04 -0400 py3: finish porting iteritems() to pycompat and remove source transformer
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 07 Oct 2019 00:04:04 -0400] rev 43106
py3: finish porting iteritems() to pycompat and remove source transformer This commit finishes porting .iteritems() to pycompat.iteritems() for the mercurial package. The translation of .iteritems() to .items() was the last conversion performed by the source transformer. With the porting to pycompat complete, we no longer have a need for the source transformer. So the source transformer has been removed. Good riddance! The code base is now compatible with Python 2 and Python 3. For the record, as the person who introduced the source transformer, it brings me joy to delete it. It accomplished its goal to facilitate a port to Python 3 without overly burdening people on some painful low-level differences between Python 2 and 3. It is unfortunate we still have to wallpaper over many differences with the pycompat shim. But it is what it is. Differential Revision: https://phab.mercurial-scm.org/D7015
Sun, 06 Oct 2019 19:25:18 -0400 py3: define and use pycompat.iteritems() for hgext/
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 19:25:18 -0400] rev 43105
py3: define and use pycompat.iteritems() for hgext/ .iteritems() -> .items() is the last source transform being performed. But it is also the most widely used. This commit adds a pycompat.iteritems symbol and imports it in place of .iteritems() for usage in hgext/. I chose to stop at just hgext/ because the patch will be large and it is an easy boundary to stop at since we can disable source transformation on a per-package basis. There are places where the type does implement items() and we could call items() directly. However, this would require critical thought and I thought it would be easier to just blindly change the code. We know which call sites need to be audited in the future because they have "pycompat.iteritems." With this change, we no longer perform source transformation on hgext! Differential Revision: https://phab.mercurial-scm.org/D7014
Sun, 06 Oct 2019 17:59:15 -0400 py3: define and use pycompat.itervalues()
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 17:59:15 -0400] rev 43104
py3: define and use pycompat.itervalues() .itervalues() only exists on Python 2. Python 3's equivalent is .values(). But we don't want to blindly use .values() everywhere because on Python 2, it will create a list, which will have performance implications. This commit introduces pycompat.itervalues() which will call the appropriate method on the passed object. We update all callers of obj.itervalues() to pycompat.itervalues(obj) instead. With this commit, the only source tranforming remaining is for iteritems(). Victory is near... Differential Revision: https://phab.mercurial-scm.org/D7013
Sun, 06 Oct 2019 17:45:05 -0400 py3: stop normalizing 2nd argument of *attr() to unicode
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 17:45:05 -0400] rev 43103
py3: stop normalizing 2nd argument of *attr() to unicode Now that we don't byteify strings, we can stop normalizing the 2nd string argument to getattr() and remove explicit overrides we were using in the code base. We no longer use some helper functions in the source transformer, so we remove those as well. Differential Revision: https://phab.mercurial-scm.org/D7012
Sun, 06 Oct 2019 14:58:41 -0400 log: populate keywords if specified in custom -Tjson(...) or -Tcbor(...)
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Oct 2019 14:58:41 -0400] rev 43102
log: populate keywords if specified in custom -Tjson(...) or -Tcbor(...) To make things simple, early return for ui.quiet is disabled if the formatter is templated and provides some datahint().
Sat, 05 Oct 2019 23:30:09 -0400 formatter: map -Tjson(...) and -Tcbor(...) to templater
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 23:30:09 -0400] rev 43101
formatter: map -Tjson(...) and -Tcbor(...) to templater Even though custom JSON output could be generated by using --config template.json="{dict(...)|json}" ..., doing that is tedious because of the trailing comma handling. This patch introduces special syntax for JSON/CBOR formats. -Tjson(...) is translated to template as if function-style template definition were supported: [templates] json(...) = "{dict(...)|json}" json(...):docheader = "[\n " json(...):docfooter = "\n]\n" json(...):separator = ",\n "
Sat, 05 Oct 2019 23:20:35 -0400 formatter: parse name of built-in formatter templates in standard way
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 23:20:35 -0400] rev 43100
formatter: parse name of built-in formatter templates in standard way This slightly makes it easier to add "-Tjson(...)" handling, which should be enabled only if the template specifier doesn't look like a literal template. In other words, it should be handled after "if '{' in tmpl". This makes "log -Tpickle" and "log -Tdebug" abort, which I think is better than just printing "picklepicklepickle...".
Sat, 05 Oct 2019 23:04:45 -0400 formatter: pass in template spec to templateformatter as argument
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 23:04:45 -0400] rev 43099
formatter: pass in template spec to templateformatter as argument Prepare for the next patch, which will unify handling of the formatter names and the template names.
Sat, 05 Oct 2019 15:47:38 -0400 templater: add public parseexpr() function to parse "-Tjson(...)"
Yuya Nishihara <yuya@tcha.org> [Sat, 05 Oct 2019 15:47:38 -0400] rev 43098
templater: add public parseexpr() function to parse "-Tjson(...)" Extracted _addparseerrorhint() to show nicer hint on error.
Sun, 06 Oct 2019 13:06:19 +0200 import: read X-Mercurial-Node email header to determine nodeid
Denis Laxalde <denis@laxalde.org> [Sun, 06 Oct 2019 13:06:19 +0200] rev 43097
import: read X-Mercurial-Node email header to determine nodeid This would be useful to import and obsolete patches sent using 'hg email --plain', using evolve's --obsolete option of 'hg import'. If email body contains Mercurial patch header ('# HG changeset patch' block), nodeid parsed from X-Mercurial-Node header will still be overridden by respective value found in body.
Wed, 02 Oct 2019 07:35:22 +0900 patchbomb: use procutil.shellquote() instead of shlex to escape email address
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Oct 2019 07:35:22 +0900] rev 43096
patchbomb: use procutil.shellquote() instead of shlex to escape email address This basically backs out 2cc453284d5c, and inserts procutil.shellquote() instead. I don't care about Windows compatibility here, but shlex.quote() can't handle byte strings on Python 3.
Mon, 07 Oct 2019 11:52:58 -0400 formatting: introduce a `test-check-format-black.t` that enforce formatting
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 07 Oct 2019 11:52:58 -0400] rev 43095
formatting: introduce a `test-check-format-black.t` that enforce formatting This should prevent use to drift away from the expect format.
Mon, 07 Oct 2019 10:58:51 -0400 formatting: run black on all file again
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 07 Oct 2019 10:58:51 -0400] rev 43094
formatting: run black on all file again Apparently, since the blackgnarok, we divergence from the expected formatting. Formatted using:: grey.py -S $(hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**" - hgext/fsmonitor/pywatchman/** - contrib/grey.py') # skip-blame mass-reformatting only # no-check-commit reformats foo_bar functions
Mon, 07 Oct 2019 11:51:34 -0400 formatting: make black --quiet in the example `hg fix` config
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 07 Oct 2019 11:51:34 -0400] rev 43093
formatting: make black --quiet in the example `hg fix` config I do like cake, but I cannot have so many of them.
Mon, 07 Oct 2019 11:48:34 -0400 formatting: remove the data-ogre from the config example
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 07 Oct 2019 11:48:34 -0400] rev 43092
formatting: remove the data-ogre from the config example Without he final `-`, black ignore the stdin and just looks at file provided as command line argument. Since `hg fix` feeds the file content through stdin and does not pass file argument, this meant black happily exited successful (all files passed as argument were formatted) without any output. Fix picked this "no output" as the new file content, deleting all previous content. I appreciate the fact this effectively removed all buggy code in any files processing that way, but this also ate all my data. The example config is now fixed in that regards.
Sun, 06 Oct 2019 17:27:51 -0400 py3: stop normalizing .encode()/.decode() arguments to unicode
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 17:27:51 -0400] rev 43091
py3: stop normalizing .encode()/.decode() arguments to unicode Now that we don't byte transform string literals, we no longer need this transform. While we're here, we also drop some superfluous u'' prefix in existing callers. Differential Revision: https://phab.mercurial-scm.org/D7011
Sun, 06 Oct 2019 16:58:55 -0400 py3: manually import pycompat.delattr where it is needed
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 16:58:55 -0400] rev 43090
py3: manually import pycompat.delattr where it is needed And with this change, we no longer need the auto-inserted import statement in the source transformer, so it has been removed! Differential Revision: https://phab.mercurial-scm.org/D7010
Sun, 06 Oct 2019 16:55:18 -0400 py3: manually import getattr where it is needed
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 16:55:18 -0400] rev 43089
py3: manually import getattr where it is needed The march continues. Differential Revision: https://phab.mercurial-scm.org/D7009
Sun, 06 Oct 2019 16:39:13 -0400 py3: stop injecting pycompat.hasattr into modules
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 16:39:13 -0400] rev 43088
py3: stop injecting pycompat.hasattr into modules I only found a single user of this pattern, probably because we use util.hasattr everywhere. Differential Revision: https://phab.mercurial-scm.org/D7008
Sun, 06 Oct 2019 14:58:42 -0400 py3: manually import pycompat.setattr where it is needed
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 14:58:42 -0400] rev 43087
py3: manually import pycompat.setattr where it is needed Continuing to eliminate the implicit import of symbols in the Python 3 source transformer so we can eliminate it. Differential Revision: https://phab.mercurial-scm.org/D7007
Sun, 06 Oct 2019 14:51:45 -0400 py3: stop implicitly importing unicode
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 14:51:45 -0400] rev 43086
py3: stop implicitly importing unicode We should be pycompat.unicode everywhere. It turns out we were doing this everywhere except for one place in templatefilters! Differential Revision: https://phab.mercurial-scm.org/D7006
Sun, 06 Oct 2019 13:28:56 -0400 py3: manually import pycompat.open into files that need it
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 13:28:56 -0400] rev 43085
py3: manually import pycompat.open into files that need it We want to eliminate the source transformer. Currently it inserts a `from mercurial.pycompat import ...` at the top of files to alias some builtins. This commit replaces the implicit import of `open` with an explicit import on files that need it and changes the source transformer to no longer import `open`. As part of this, we needed to store an explicit local for `open` in the Python 2 code path in `pycompat` so the import works. (Builtins that are automatically in scope cannot be imported.) Differential Revision: https://phab.mercurial-scm.org/D7005
Sun, 06 Oct 2019 13:17:19 -0400 import-checker: allow symbol imports from mercurial.pycompat
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Oct 2019 13:17:19 -0400] rev 43084
import-checker: allow symbol imports from mercurial.pycompat Currently, the source transformer inserts `from mercurial.pycompat import delattr, getattr, hasattr, setattr, open, unicode` to the top of every file. As part of getting rid of the source transformer, we'll need to have source code call these wrappers directly. Rather than rewrite all call sites to call pycompat.*, I think it makes sense to import needed symbols via explicit imports. That requires loosening the import checker to allow this. Differential Revision: https://phab.mercurial-scm.org/D7004
Sun, 06 Oct 2019 14:13:03 -0700 contrib: add a fork of black (as "grey") that includes my changes
Augie Fackler <augie@google.com> [Sun, 06 Oct 2019 14:13:03 -0700] rev 43083
contrib: add a fork of black (as "grey") that includes my changes This is black with https://github.com/psf/black/pull/826 applied as of today. The current git hash of black master is d9e71a75ccfefa3d9156a64c03313a0d4ad981e5, and the hash of my commit is dc1add6e94e212eff37bb3619e1422fb3c6d8dc8. In order to use this, you need to install `black` (from github master) and `typed-ast` using pip, preferably into python3, and then you can run `grey.py` with that Python and you'll have my patched version of black, which is how we've been formatting the codebase. Once my PR is merged, I'll follow up by removing this fork and updating instructions in the example config. # no-check-commit bad style Differential Revision: https://phab.mercurial-scm.org/D7002
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -32 +32 +50 +100 +300 +1000 +3000 tip