Sun, 29 Mar 2020 01:57:17 +0900 debugcommands: fix typo in debuguigetpass
Yuya Nishihara <yuya@tcha.org> [Sun, 29 Mar 2020 01:57:17 +0900] rev 44660
debugcommands: fix typo in debuguigetpass
Thu, 26 Mar 2020 22:31:17 +0900 dagop: fix subsetparentswalker to set p1/p2 chains at merge revision
Yuya Nishihara <yuya@tcha.org> [Thu, 26 Mar 2020 22:31:17 +0900] rev 44659
dagop: fix subsetparentswalker to set p1/p2 chains at merge revision The previous implementation was wrong because the '1'/'2' key would be appended at a fork revision. Since we traverse the graph from heads, a merge revision is actually a branching point, where the sort key must be generated.
Thu, 26 Mar 2020 22:23:30 +0900 dagop: simplify dict/set reuse condition in subsetparentswalker
Yuya Nishihara <yuya@tcha.org> [Thu, 26 Mar 2020 22:23:30 +0900] rev 44658
dagop: simplify dict/set reuse condition in subsetparentswalker Prepares for fixing the calculation of p1/p2 sort keys. With this change, there will be one more copying on merge&fork case. I think the copying cost is negligible since we'll have to update each item in the dict on merge/fork.
Sun, 29 Mar 2020 14:22:07 -0700 extensions: refactor function for obtaining disabled extension help
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 29 Mar 2020 14:22:07 -0700] rev 44657
extensions: refactor function for obtaining disabled extension help The way this worked before was hgext.__index__ was consulted. This file appears to only be present on some Windows distributions. This file contains a dict mapping extension name to its summary line, not its full docstring. The problem with this is that code in the help system was calling this function to resolve help text. If hgext.__index__ was present, only the summary line would be displayed. If not, the full extension help would be printed. This commit changes the function to not use hgext.__index__ such that it always returns the full extension help text. As a result of this change, test-extension.t and test-qrecord.t now pass when run from environments that have an hgext.__index__. Differential Revision: https://phab.mercurial-scm.org/D8344
Sun, 29 Mar 2020 15:29:39 -0700 tests: perform grep manually in test-doctest.py
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 29 Mar 2020 15:29:39 -0700] rev 44656
tests: perform grep manually in test-doctest.py This test has been failing on Windows since 0af56d3ee24c introduced the `hg files` invocation. Specifically, Windows seems to be choking on special characters in the fileset pattern. I believe at least \n and > were causing issues. I attempted various incantations to make the Windows command line parser accept the fileset but couldn't get anything working. I declared bankruptcy and just reimplemented the grepping code in Python. After this change, the test now passes on Windows again. Differential Revision: https://phab.mercurial-scm.org/D8343
Sun, 29 Mar 2020 14:31:59 -0700 tests: prevent printing \r to stdout
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 29 Mar 2020 14:31:59 -0700] rev 44655
tests: prevent printing \r to stdout Like we've done in other recent commits, we need to change sys.stdout on Python 3 to not use os.linesep so output is consistent on Python 3 on Windows. With this change, test-notify.t now passes on Python 3 on Windows! Differential Revision: https://phab.mercurial-scm.org/D8342
Sun, 29 Mar 2020 13:51:26 -0700 tests: force \n newlines when writing to sys.stdout
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 29 Mar 2020 13:51:26 -0700] rev 44654
tests: force \n newlines when writing to sys.stdout Without this, Python 3 on Windows inserts some \r that aren't present in the input, causing test-http-bad-server.t to fail. After this change, the test passes on Python 3 on Windows! Differential Revision: https://phab.mercurial-scm.org/D8341
Sun, 29 Mar 2020 13:06:59 -0700 dispatch: force \n for newlines on sys.std* streams (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 29 Mar 2020 13:06:59 -0700] rev 44653
dispatch: force \n for newlines on sys.std* streams (BC) The sys.std* streams behave differently on Python 3. On Python 3, these streams are an io.TextIOWrapper that wraps a binary buffer stored on a .buffer attribute. These TextIOWrapper instances normalize \n to os.linesep by default. On Windows, this means that \n is normalized to \r\n. So functions like print() which have an implicit end='\n' will actually emit \r\n for line endings. While most parts of Mercurial go through the ui.write() layer to print output, some code - notably in extensions and hooks - can use print(). If this code was using print() or otherwise writing to sys.std* on Windows, Mercurial would emit \r\n. In reality, pretty much everything on Windows reacts to \n just fine. Mercurial itself doesn't emit \r\n when going through the ui layer. Changing the sys.std* streams to not normalize line endings sounds like a scary change. But I think it is safe. It also makes Mercurial on Python 3 behave similarly to Python 2, which did not perform \r\n normalization in print() by default. .. bc:: sys.{stdout, stderr, stdin} now use \n line endings on Python 3 Differential Revision: https://phab.mercurial-scm.org/D8339
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 tip