morestatus: move fb extension to core by plugging to `hg status --verbose` morestatus extension in fbext use to show more context about the state of the repo like the repository is in a unfinished merge state, or a rebase is going on, or histedit is going on, listing the files which need to be resolved and also suggesting ways to handle the situation. This patch moves the extension directly to core by plugging it into the --verbose flag of the status command. So now if you are in any unfinished state and you do hg status -v, it will show you details and help related to the state. The extension in fbext also shows context about unfinished update state which is not ported to core as that plug in hooks to update command which need to be tackled somewhat differently. The following configuration will turn the behaviour on by default [commands] status.verbose = 1 You can also skip considering some states like bisect as follows: [commands] status.skipstates=bisect This patch also adds test for the feature. .. feature:: ``hg status -v`` can now show unfinished state. For example, when in an unfinished rebase state, ``hg status -v`` might show:: # The repository is in an unfinished *rebase* state. # No unresolved merge conflicts. # To continue: hg rebase --continue # To abort: hg rebase --abort Differential Revision: https://phab.mercurial-scm.org/D219

bundle2: fix transaction availability detection Changeset 5fc4ddfbe626 introduce more complex logic around 'bundleoperation.gettransaction'. In that process it turns the old "attribute" into a proper method which breaks the code that detects the "transaction availability". The change was visible in 'test-acl.t', fixing this reverts the test changes. Differential Revision: https://phab.mercurial-scm.org/D303

fsmonitor: correct an error message Without the change, the error looks like: warning: Watchman unavailable: "watchman" executable not in PATH (%s), while executing [Errno 2] No such file or directory With the change, it now looks like: warning: Watchman unavailable: "watchman" executable not in PATH ([Errno 2] No such file or directory) Differential Revision: https://phab.mercurial-scm.org/D322

sshpeer: make instance attributes and methods internal Peer types are supposed to conform to a formal interface defined by peer.peerrepository and wireproto.wirepeer. Every "public" attribute on *peer types makes it harder to understand what attributes are part of the interface and what are instance specific. This commit converts a number of "public" instance attributes and methods on sshpeer to internal so they can't be confused to be part of the peer API. The URL-related instance attributes were introduced in 876333a295ff in 2005. AFAICT most of them aren't used and could potentially be removed. But I kept them around anyway. I also reorded some code to make things slightly easier to read. .. api:: Rename attributes on sshpeer to reflect peer API Differential Revision: https://phab.mercurial-scm.org/D331

peer: remove non iterating batcher (API) The last use of this API was removed in b6e71f8af5b8 in 2016. While not formally deprecated, as of the last commit the code is no longer explicitly tested. I think the new API has existed long enough for people to transition to it. I also have plans to more formalize the peer API and removing batch() makes that work easier. I'm not convinced the current client-side API around batching is great. But it's the best we have at the moment. .. api:: remove peer.batch() Replace with peer.iterbatch(). Differential Revision: https://phab.mercurial-scm.org/D320

wireproto: overhaul iterating batcher code (API) The remote batching code is difficult to read. Let's improve it. As part of the refactor, the future returned by method calls on batchiter() instances is now populated. However, you still need to consume the results() generator for the future to be set. But at least now we can stuff the future somewhere and not have to worry about aligning method call order with result order since you can use a future to hold the result. Also as part of the change, we now verify that @batchable generators yield exactly 2 values. In other words, we enforce their API. The non-iter batcher has been unused since b6e71f8af5b8. And to my surprise we had no explicit unit test coverage of it! test-batching.py has been overhauled to use the iterating batcher. Since the iterating batcher doesn't allow non-batchable method calls nor local calls, tests have been updated to reflect reality. The iterating batcher has been used for multiple releases apparently without major issue. So this shouldn't cause alarm. .. api:: @peer.batchable functions must now yield exactly 2 values Differential Revision: https://phab.mercurial-scm.org/D319