Thu, 01 Feb 2018 16:59:18 -0800 wireprotoserver: move responsetype() out of http handler
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 01 Feb 2018 16:59:18 -0800] rev 36110
wireprotoserver: move responsetype() out of http handler This is our last public attribute not part of the protocol interface! Differential Revision: https://phab.mercurial-scm.org/D2087
Wed, 07 Feb 2018 20:22:44 -0800 wireproto: remove unused proto argument from supportedcompengines (API)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:22:44 -0800] rev 36109
wireproto: remove unused proto argument from supportedcompengines (API) In theory, the protocol should be passed to this function. But the argument isn't being used and it is getting in the way of refactoring. So let's remove it. We can always add it back later if we need it again. Differential Revision: https://phab.mercurial-scm.org/D2086
Thu, 01 Feb 2018 17:12:07 -0800 wireprotoserver: rename getfile() to forwardpayload() (API)
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 01 Feb 2018 17:12:07 -0800] rev 36108
wireprotoserver: rename getfile() to forwardpayload() (API) "file" can mean a lot of things. Let's rename the interface method to something more descriptive. While I was here, I moved the docs about the payload format to the implementation of the SSH protocol, because it was lying about what the HTTP payload looked like. Differential Revision: https://phab.mercurial-scm.org/D2085
Wed, 07 Feb 2018 20:24:22 -0800 wireprotoserver: rename _client to client (API)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:24:22 -0800] rev 36107
wireprotoserver: rename _client to client (API) This method is called in wireproto.py. It should be part of the public API/interface. .. api:: The ``_client()`` method of the wire protocol handler interface has been renamed to ``client()``. Differential Revision: https://phab.mercurial-scm.org/D2084
Wed, 07 Feb 2018 20:20:11 -0800 wireprotoserver: remove redirect() and restore() (API)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:20:11 -0800] rev 36106
wireprotoserver: remove redirect() and restore() (API) These methods on the protocol handler interface are no longer used in core. .. api:: redirect() and restore() have been removed from the wire protocol handler interface. Use mayberedirectstdio() instead. Differential Revision: https://phab.mercurial-scm.org/D2083
Wed, 07 Feb 2018 20:19:06 -0800 wireproto: use maybecapturestdio() for push responses (API)
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:19:06 -0800] rev 36105
wireproto: use maybecapturestdio() for push responses (API) The "pushres" and "pusherr" response types currently call proto.restore() in the HTTP protocol. This completes the pairing with proto.redirect() that occurs in the @wireprotocommand functions. (But since the SSH protocol has a no-op redirect(), it doesn't bother calling restore() because it would also be a no-op.) Having the disconnect between these paired calls is very confusing. Knowing that you must use proto.redirect() if returning a "pushres" or a "pusherr" is even wonkier. We replace this confusing code with our new context manager for [maybe] capturing output. The "pushres" and "pusherr" types have gained an "output" argument to their constructor and an attribute to hold captured data. The HTTP protocol now retrieves output from these objects. .. api:: ``wireproto.pushres`` and ``wireproto.pusherr`` now explicitly track stdio output. Differential Revision: https://phab.mercurial-scm.org/D2082
Wed, 07 Feb 2018 20:17:47 -0800 wireprotoserver: add context manager mechanism for redirecting stdio
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:17:47 -0800] rev 36104
wireprotoserver: add context manager mechanism for redirecting stdio Today, proto.redirect() sets up redirecting stdio and proto.restore() undoes that. The API is a bit wonky because restore() is only implemented on the HTTP protocol. Furthermore, not all calls to redirect() are obviously paired with calls to restore(). For example, the call to restore() for "unbundle" requests is handled by the response handler for the HTTP protocol. This commit introduces a new method on the protocol handler interface to maybe capture stdio. It emits a file object or None depending on whether stdio capture is used by the transport. To prove it works, the "pushkey" wire protocol command has been updated to use the new API. I'm not convinced this is the best mechanism to capture stdio. I may need to come up with something better once the new wire protocol emerges into existence. But it is strictly better than before because it removes variance in the wire protocol handler interface. It therefore gets us closer to a unified interface between the SSH and HTTP transports. Differential Revision: https://phab.mercurial-scm.org/D2081
Wed, 07 Feb 2018 20:17:05 -0800 wireprotoserver: split ssh protocol handler and server
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 20:17:05 -0800] rev 36103
wireprotoserver: split ssh protocol handler and server We want to formalize the interface for protocol handlers. Today, server functionality (which is domain specific) is interleaved with protocol handling functionality (which conforms to a generic interface) in the sshserver class. This commit splits the ssh protocol handling code out of the sshserver class. Differential Revision: https://phab.mercurial-scm.org/D2080
Wed, 07 Feb 2018 21:04:54 -0800 wireprotoserver: extract SSH response handling functions
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Feb 2018 21:04:54 -0800] rev 36102
wireprotoserver: extract SSH response handling functions The lookup/dispatch table was cute. But it isn't needed. Future refactors will benefit from the handlers for individual response types living outside the class. As part of this, I snuck in a change that changes a type compare from str to bytes. This has no effect on Python 2. But it might make Python 3 a bit happier. Differential Revision: https://phab.mercurial-scm.org/D2091
Sat, 23 Dec 2017 15:13:37 +0530 remotenames: introduce new template keywords for remotenames
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 15:13:37 +0530] rev 36101
remotenames: introduce new template keywords for remotenames This patch introduces three new template keywords 'remotenames', 'remotebookmarks', 'remotebranches' to show remotenames, remotebookmarks and remotebranches associated to a changeset. This is a part of moving hgremotenames extension to core. The remotenames template keyword was present in the extension and the rest of the two are not present in the hgremotenames extension and are introduced in this patch. hgremotenames: https://bitbucket.org/seanfarley/hgremotenames Differential Revision: https://phab.mercurial-scm.org/D1759
Sat, 23 Dec 2017 14:24:41 +0530 remotenames: add new namespaces for remotebookmarks and remotebranches
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 14:24:41 +0530] rev 36100
remotenames: add new namespaces for remotebookmarks and remotebranches This patch adds two new namespaces which will be enabled by remotenames extension. The namespaces are remotebookmarks and remotebranches. Adding them as namespaces will show them in various commands' output such as log, show work. This will also unable to access changesets using that name. Tests are also added for the same. This is a part of moving hgremotenames extension to core. hgremotenames: https://bitbucket.org/seanfarley/hgremotenames Differential Revision: https://phab.mercurial-scm.org/D1758
Sat, 23 Dec 2017 17:50:42 +0530 remotenames: introduce a class to lazily resolve remotnames
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 17:50:42 +0530] rev 36099
remotenames: introduce a class to lazily resolve remotnames remotenames may take time to load and in next patch we are going to introduce namespaces related to them. So let's introduce a class making them load lazily. This is a part of moving hgremotenames extension to core. hgremotenames: https://bitbucket.org/seanfarley/hgremotenames Differential Revision: https://phab.mercurial-scm.org/D1757
Sat, 23 Dec 2017 00:19:09 +0530 remotenames: introduce class to encapsulate remotenames info in an extension
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 00:19:09 +0530] rev 36098
remotenames: introduce class to encapsulate remotenames info in an extension This patch adds a new extension remotenames in which features from hgremotenames extension (https://bb/seanfarley/hgremotenames) will be added incrementally. This patch introduces a basic class to encapsulate the remotenames information. Differential Revision: https://phab.mercurial-scm.org/D1756
Sat, 23 Dec 2017 20:27:41 +0530 logexchange: introduce helper function to get remote path name
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 23 Dec 2017 20:27:41 +0530] rev 36097
logexchange: introduce helper function to get remote path name This patch moves chunk of activepath function from hgremotenames extension (https://bitbucket.org/seanfarley/hgremotenames/) to core. Before moving rest of the part, there needs to be some refactoring done to schemes which will be done as a separate series. Differential Revision: https://phab.mercurial-scm.org/D1755
Mon, 12 Feb 2018 10:36:59 -0500 charencode: adjust clang-format enable/disable comments
Augie Fackler <augie@google.com> [Mon, 12 Feb 2018 10:36:59 -0500] rev 36096
charencode: adjust clang-format enable/disable comments We're pretty close to being able to let clang-format manage most of these files. Differential Revision: https://phab.mercurial-scm.org/D2180
Mon, 12 Feb 2018 10:31:17 -0500 diffhelpers: allow clang-format oversight
Augie Fackler <augie@google.com> [Mon, 12 Feb 2018 10:31:17 -0500] rev 36095
diffhelpers: allow clang-format oversight One trailing comma! Differential Revision: https://phab.mercurial-scm.org/D2179
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip