Sun, 30 Sep 2018 15:37:09 +0900 grep: rename {line_number} to {lineno} as well (BC)
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Sep 2018 15:37:09 +0900] rev 39930
grep: rename {line_number} to {lineno} as well (BC)
Sun, 30 Sep 2018 15:35:17 +0900 annotate: rename {line_number} to {lineno} (BC)
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Sep 2018 15:35:17 +0900] rev 39929
annotate: rename {line_number} to {lineno} (BC) I think {lineno} looks more like a common template keyword. It isn't called a {line} to avoid conflicts with the element name of {lines} and the {_|splitlines} filter. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
Sun, 30 Sep 2018 15:15:27 +0900 resolve: rename {status} to {mergestatus} to not shadow change status (BC)
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Sep 2018 15:15:27 +0900] rev 39928
resolve: rename {status} to {mergestatus} to not shadow change status (BC) This is a part of the name unification. I think it's somewhat useful to provide a combined view of change/merge statuses. https://www.mercurial-scm.org/wiki/GenericTemplatingPlan#Dictionary
Mon, 01 Oct 2018 09:06:01 -0400 py3: whitelist one additional test
Augie Fackler <augie@google.com> [Mon, 01 Oct 2018 09:06:01 -0400] rev 39927
py3: whitelist one additional test Differential Revision: https://phab.mercurial-scm.org/D4817
Fri, 03 Nov 2017 21:11:07 +0100 logtoprocess: connect all fds to /dev/null to avoid bad interaction with pager
Boris Feld <boris.feld@octobus.net> [Fri, 03 Nov 2017 21:11:07 +0100] rev 39926
logtoprocess: connect all fds to /dev/null to avoid bad interaction with pager We detected that pager is waiting for log-to-process script to finish, which is annoying when adding a script on commandfinish that does an HTTP push. There seems to be no workaround on the script side and it will make the behavior on Linux/MacOS closer to the Windows behavior. The drawback is that it makes the related tests more flaky as log-to-process outputs are now really asynchronous. If it's considered a BC change, another option would be to add a config option for this new behavior. I personally think that the different behavior between Windows and Linux is confusing and that it's a bug I would be fine with a new config option. Differential Revision: https://phab.mercurial-scm.org/D4816
Fri, 03 Nov 2017 21:35:36 +0100 logtoprocess: add a test to show pager and ltp bad interaction
Boris Feld <boris.feld@octobus.net> [Fri, 03 Nov 2017 21:35:36 +0100] rev 39925
logtoprocess: add a test to show pager and ltp bad interaction The next changeset will fix the bad interaction between the pager and log-to- process. Add a test first to make the next changeset easier to understand. Differential Revision: https://phab.mercurial-scm.org/D4815
Sun, 30 Sep 2018 21:13:16 +0300 py3: add one more passing test to whitelist caught by buildbot
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 21:13:16 +0300] rev 39924
py3: add one more passing test to whitelist caught by buildbot Thanks to Matt Harbison who fixed the remaining failures of this test. Differential Revision: https://phab.mercurial-scm.org/D4814
Thu, 27 Sep 2018 12:06:32 +0200 cleanupnodes: pass multiple predecessors to `createmarkers` directly
Boris Feld <boris.feld@octobus.net> [Thu, 27 Sep 2018 12:06:32 +0200] rev 39923
cleanupnodes: pass multiple predecessors to `createmarkers` directly
Sat, 22 Sep 2018 14:40:33 +0200 obsolete: allow multiple predecessors in createmarkers
Boris Feld <boris.feld@octobus.net> [Sat, 22 Sep 2018 14:40:33 +0200] rev 39922
obsolete: allow multiple predecessors in createmarkers The logic for this change is similar to the change to `cleanupnodes` that we did earlier. Now that the rebase code is trying to record a fold, we need to actually record it in the markers. The first step is to have the markers creation API able to receive such fold data. To keep things sane, we restrict fold to on successors.
Wed, 26 Sep 2018 21:03:09 +0200 obsolete: preindent code in createmarkers
Boris Feld <boris.feld@octobus.net> [Wed, 26 Sep 2018 21:03:09 +0200] rev 39921
obsolete: preindent code in createmarkers This will help to make the next change clearer.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip