Mon, 01 Oct 2018 23:04:58 -0400 lfs: explicitly name a key when sorting blob pointers
Matt Harbison <matt_harbison@yahoo.com> [Mon, 01 Oct 2018 23:04:58 -0400] rev 39950
lfs: explicitly name a key when sorting blob pointers This is needed to keep py3 happy. The other two instances of sorting already did this.
Mon, 01 Oct 2018 21:54:00 -0400 py3: byteify test-lock.py
Matt Harbison <matt_harbison@yahoo.com> [Mon, 01 Oct 2018 21:54:00 -0400] rev 39949
py3: byteify test-lock.py There's still a stacktrace about not being able to serialize _io.TextIOWrapper.
Mon, 01 Oct 2018 21:48:45 -0400 py3: byteify contrib/dumprevlog
Matt Harbison <matt_harbison@yahoo.com> [Mon, 01 Oct 2018 21:48:45 -0400] rev 39948
py3: byteify contrib/dumprevlog
Mon, 01 Oct 2018 19:39:05 -0400 py3: quote $PYTHON in test-merge-symlinks.t
Matt Harbison <matt_harbison@yahoo.com> [Mon, 01 Oct 2018 19:39:05 -0400] rev 39947
py3: quote $PYTHON in test-merge-symlinks.t
Thu, 21 Jun 2018 22:07:34 -0700 copies: inline a variable that's used only once
Martin von Zweigbergk <martinvonz@google.com> [Thu, 21 Jun 2018 22:07:34 -0700] rev 39946
copies: inline a variable that's used only once By inlining it, we also avoid calculating the value when "if of in seen" is false (probably not significant). Differential Revision: https://phab.mercurial-scm.org/D4831
Sat, 15 Sep 2018 22:56:57 -0700 bundlerepo: remove a variable alias
Martin von Zweigbergk <martinvonz@google.com> [Sat, 15 Sep 2018 22:56:57 -0700] rev 39945
bundlerepo: remove a variable alias "parentrepo" and "repo" were the same thing and I don't see much reason for it (unionrepo has similar structure and a similar alias but there are two repos there so at least it makes a little more sense there). Differential Revision: https://phab.mercurial-scm.org/D4830
Mon, 01 Oct 2018 16:11:48 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 01 Oct 2018 16:11:48 -0400] rev 39944
merge with stable
Fri, 28 Sep 2018 12:05:48 -0700 narrow: move support for `hg verify` into core
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 12:05:48 -0700] rev 39943
narrow: move support for `hg verify` into core Differential Revision: https://phab.mercurial-scm.org/D4824
Fri, 28 Sep 2018 13:55:17 -0700 narrow: drop unnecessary overrides of patch
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 13:55:17 -0700] rev 39942
narrow: drop unnecessary overrides of patch The patch overrides became unnecessary when I made context.status() filter by the narrowspec in e411774a2e0f (narrow: move status-filtering to core and to ctx, 2018-08-02). Differential Revision: https://phab.mercurial-scm.org/D4823
Fri, 28 Sep 2018 00:00:36 -0700 tests: add test showing that paths outside narrowspec are not added
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 00:00:36 -0700] rev 39941
tests: add test showing that paths outside narrowspec are not added We had a test that shows that trying to explicitly add a file outside the narrowspec results in an error, but we didn't have a test that shows that paths from subdirectories outside the narrowspec are not added (on e.g. `hg add .`) but silently ignored. Differential Revision: https://phab.mercurial-scm.org/D4822
Mon, 01 Oct 2018 09:05:41 -0400 catapipe: fix bug introduced when switching to the timer api
Augie Fackler <augie@google.com> [Mon, 01 Oct 2018 09:05:41 -0400] rev 39940
catapipe: fix bug introduced when switching to the timer api Differential Revision: https://phab.mercurial-scm.org/D4818
Sun, 30 Sep 2018 03:45:51 +0530 narrow: move the ellipses server capability to core
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 03:45:51 +0530] rev 39939
narrow: move the ellipses server capability to core This will be used in core logic to determining whether a server is ellipses enabled or not. And also this will ease moving narrow related things to core. Differential Revision: https://phab.mercurial-scm.org/D4809
Sun, 30 Sep 2018 03:42:35 +0530 narrow: move the wireprotocol narrow capability name to core
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 30 Sep 2018 03:42:35 +0530] rev 39938
narrow: move the wireprotocol narrow capability name to core We are trying to integrate the whole of narrow logic into core and it will be helpful for upcoming patches to have these capability names in core. The next patch will move the ellipses capability to core also. The exact motivation is to know whether we are cloning a ellipses repo or not and adding an ellipses repo requirement. Differential Revision: https://phab.mercurial-scm.org/D4808
Sun, 30 Sep 2018 16:11:35 +0900 help: document about "files" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Sep 2018 16:11:35 +0900] rev 39937
help: document about "files" template keywords
Sun, 30 Sep 2018 15:53:36 +0900 formatter: remove experimental marker from -T option
Yuya Nishihara <yuya@tcha.org> [Sun, 30 Sep 2018 15:53:36 +0900] rev 39936
formatter: remove experimental marker from -T option I think it's good enough to stabilize the feature, at least for the core and non-experimental commands.
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 39935
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 39934
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 39933
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 39932
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 39931
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 39930
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 39929
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 39928
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 39927
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 39926
obsolete: preindent code in createmarkers This will help to make the next change clearer.
Wed, 26 Sep 2018 23:37:43 +0200 obsolete: explicitly pass relation items to effectflag computation
Boris Feld <boris.feld@octobus.net> [Wed, 26 Sep 2018 23:37:43 +0200] rev 39925
obsolete: explicitly pass relation items to effectflag computation To track folds, we are about to change the content of `rel`. To simplify this change, we update the `geteffectflag` function beforehand.
Wed, 26 Sep 2018 22:45:44 +0200 rebase: explicitly track collapses as fold
Boris Feld <boris.feld@octobus.net> [Wed, 26 Sep 2018 22:45:44 +0200] rev 39924
rebase: explicitly track collapses as fold A collapse is a large fold. It is now explicitly tracked (at the cleanupnodes API level).
Wed, 26 Sep 2018 23:51:11 +0200 rebase: use tuple as `replacement` keys
Boris Feld <boris.feld@octobus.net> [Wed, 26 Sep 2018 23:51:11 +0200] rev 39923
rebase: use tuple as `replacement` keys Now that `cleanupnodes` support tuples as key, we update the rebase code to use them. No changes in the replacement tracked are introduced yet.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip