Sat, 29 Dec 2018 23:40:18 -0800 narrow: move copytonarrowspec() out of setnarrowpats()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:40:18 -0800] rev 41236
narrow: move copytonarrowspec() out of setnarrowpats() I think it was a mistake to write the working copy's narrowspec every time the store narrowspec is written. This starts separating those actions. Differential Revision: https://phab.mercurial-scm.org/D5509
Sat, 29 Dec 2018 23:09:07 -0800 narrow: drop now-unnecessary reassignment of repo attributes
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:09:07 -0800] rev 41235
narrow: drop now-unnecessary reassignment of repo attributes Differential Revision: https://phab.mercurial-scm.org/D5507
Fri, 11 Jan 2019 14:55:31 +0100 packaging: allow running packaging with custom uid+gid for CentOS
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 11 Jan 2019 14:55:31 +0100] rev 41234
packaging: allow running packaging with custom uid+gid for CentOS rpmbuild in CentOS 7 has a bug causing rpmbuild to fail with "Bad owner/group" if spec or source files are owned by a different user: https://github.com/rpm-software-management/rpm/issues/2 This makes it very annoying to try and build the CentOS RPMs on CentOS with Docker. As an alternative, this change makes it possible to do so, using an environment variable. Differential Revision: https://phab.mercurial-scm.org/D5571
Fri, 11 Jan 2019 13:14:25 +0100 hg-docker: fix Python 3.4 compatibility (for CentOS 7)
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 11 Jan 2019 13:14:25 +0100] rev 41233
hg-docker: fix Python 3.4 compatibility (for CentOS 7) I realize Mercurial is not targetting Python 3.4 compatibility, but without this change, it's not even possible to build it on CentOS 7 (and I assume the same is true for RHEL 7). Differential Revision: https://phab.mercurial-scm.org/D5570
Tue, 15 Jan 2019 11:07:34 -0800 copies: use node.nullrev instead of literal -1
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Jan 2019 11:07:34 -0800] rev 41232
copies: use node.nullrev instead of literal -1 Differential Revision: https://phab.mercurial-scm.org/D5593
Tue, 15 Jan 2019 09:20:47 -0800 copies: use node.wdirrev instead of inventing another constant for it
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Jan 2019 09:20:47 -0800] rev 41231
copies: use node.wdirrev instead of inventing another constant for it Differential Revision: https://phab.mercurial-scm.org/D5592
Sat, 29 Dec 2018 23:35:05 -0800 narrow: extract repo property for store narrowmatcher
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:35:05 -0800] rev 41230
narrow: extract repo property for store narrowmatcher When a repo lock is released, we try to persist the manifest cache. That involves getting the narrowmatcher for the manifestlog. That should not fail if the store and working copy narrowspecs are out of sync. Without this patch, the later patches in this series will fail because of that. Differential Revision: https://phab.mercurial-scm.org/D5508
Sat, 29 Dec 2018 23:01:12 -0800 narrow: copy store narrowspec to working copy immediately
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:01:12 -0800] rev 41229
narrow: copy store narrowspec to working copy immediately We no longer need to delay it until the end of the transaction since we now restore a backup if the transaction aborts. Differential Revision: https://phab.mercurial-scm.org/D5506
Sat, 29 Dec 2018 22:34:38 -0800 narrow: include working copy narrowspec in transaction journal
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 22:34:38 -0800] rev 41228
narrow: include working copy narrowspec in transaction journal Now that we have separate narrowspecs for the store and the working copy, we need to include both in the transaction journal. Differential Revision: https://phab.mercurial-scm.org/D5505
Sat, 29 Dec 2018 22:27:39 -0800 narrow: make dirstateguard back up and restore working copy narrowspec instead
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 22:27:39 -0800] rev 41227
narrow: make dirstateguard back up and restore working copy narrowspec instead We used to have only one narrowspec for the store and the working copy, but now that we have one narrowspec for each, it seems clear that the dirstateguard was supposed to back up and restore the narrowspec associated with the working copy, not the one associated with the store. clearbackup() (for the store narrowspec) is not needed because the presence of the file in localrepository._journalfiles() takes care of that. Differential Revision: https://phab.mercurial-scm.org/D5504
Thu, 10 Jan 2019 13:36:25 -0800 narrow: include journal.narrowspec in transaction journal
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Jan 2019 13:36:25 -0800] rev 41226
narrow: include journal.narrowspec in transaction journal We had missed this file before, which led to it lying around after the transaction completed. Differential Revision: https://phab.mercurial-scm.org/D5556
Tue, 08 Jan 2019 09:50:40 -0800 progress: deprecate ui.progress()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 09:50:40 -0800] rev 41225
progress: deprecate ui.progress() It is now just a weird wrapper for ui.makeprogress(). Differential Revision: https://phab.mercurial-scm.org/D5531
Tue, 15 Jan 2019 15:43:00 -0800 context: use scmutil.matchfiles instead of matchmod.match(exact=True)
Kyle Lippincott <spectral@google.com> [Tue, 15 Jan 2019 15:43:00 -0800] rev 41224
context: use scmutil.matchfiles instead of matchmod.match(exact=True) Differential Revision: https://phab.mercurial-scm.org/D5591
Mon, 14 Jan 2019 22:19:43 -0500 histedit: fix call to _getgoal() by adding a byteskwargs() wrapper
Augie Fackler <augie@google.com> [Mon, 14 Jan 2019 22:19:43 -0500] rev 41223
histedit: fix call to _getgoal() by adding a byteskwargs() wrapper I also added some b-prefixes while I was here because I got confused and it seems silly to not just add them since it clarifies the whole change. Differential Revision: https://phab.mercurial-scm.org/D5585
Fri, 04 Jan 2019 13:41:21 +0100 revset: introduce an API that avoids `formatspec` input serialization
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 13:41:21 +0100] rev 41222
revset: introduce an API that avoids `formatspec` input serialization Instead of having the data fully serialized, the input can be directly inserted in the tree at a later stage. Just using it for simple "%ld" case provide a significant boost. For example here are the impact on a sample discovery run between two pypy repositories with arbitrary differences (using hg perfdiscovery). $ hg perfdiscovery before: ! wall 0.700435 comb 0.710000 user 0.700000 sys 0.010000 (median of 15) after: ! wall 0.501305 comb 0.510000 user 0.490000 sys 0.020000 (median of 20)
Fri, 04 Jan 2019 05:26:13 +0100 revset: detect integer list on parsing
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 05:26:13 +0100] rev 41221
revset: detect integer list on parsing Right now, using "%ld" with `repo.revs("…%ld…", somerevs)` is very inefficient, all items in `somerevs` will be serialized to ascii and then reparsed as integers. If `somerevs` contains just an handful of entry this is fine, however, when you get to thousands or hundreds of thousands of revisions this becomes very slow. To avoid this serialization we need to first detect this situation. The code involved in the whole process is quite complex so we start simple and focus on some "simple" but widespread cases. So far we only detect the situation and don't do anything special about it. The singled out will be serialized in `formatspec` in the same way as before.
Fri, 04 Jan 2019 05:16:57 +0100 revert: extract "%ld" formatting in a _formatintlist function
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 05:16:57 +0100] rev 41220
revert: extract "%ld" formatting in a _formatintlist function We'll have to reuse this logic in different places.
Fri, 04 Jan 2019 02:29:04 +0100 revset: extract parsing logic out of formatspec
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 02:29:04 +0100] rev 41219
revset: extract parsing logic out of formatspec We want to be able to perform better handling of some input when running revset (eg: `repo.revs("%ld", somerevs)`). The first step is to be able to access some of the parsed content before it gets substituted. There are many possible different substitutions, we'll add support for them gradually. In this changeset we support none, we just split some logic in a sub function as a preparatory step.
Thu, 10 Jan 2019 15:23:58 +0100 revset: enforce "%d" to be interpreted as literal revision number (API) (BC)
Boris Feld <boris.feld@octobus.net> [Thu, 10 Jan 2019 15:23:58 +0100] rev 41218
revset: enforce "%d" to be interpreted as literal revision number (API) (BC) Before this change, `formatspec("%d", x)` results in `"%d" % int(x)`. This seems simple and correct until you consider `nullrev`. In revset, a direct "-1" symbol is equivalent to `tip` not `nullrev`. This is a subtle error that went undetected for a while. Wrapping the revision number inside 'rev()' remove the ambiguity, preserving nullrev value passed to formatspec. It got caught by the rebase code, were the following wrongly returned `[1]`: repo.revs("children(%d) and ancestors(%ld)", 0, [nullrev]) This is flagged as API, because `%d` can be used for non-revision integer argument of revset function. We probably need to introduce a new '%…' substitution to allow literal integer (maybe `%i`). However, the `%d` usage is currently widespread for revision number so it is important to fix this issue for `%d`. This choice is reinforced by the fact _intlist is implemented as revisions only. Restricting `%d` to revision only makes things more consistent. This bug can become especially tricky since `_intlist` recognize `nullrev` right. So `revs('%ld', [-1, 0])` → select `[nullrev, 0]` but `revs('%ld', [-1])` is simplified and treated as `%d` selecting `[tip]`. Another side effect is that "%d" of an unknown revision simply match nothing. It was previously raising and error. This is consistent with what "%ld" (and `_intlist`) is doing, so it seems like a good move.
Thu, 10 Jan 2019 16:03:07 +0100 revset: remove the last usage of "%d" for a non-revision entry
Boris Feld <boris.feld@octobus.net> [Thu, 10 Jan 2019 16:03:07 +0100] rev 41217
revset: remove the last usage of "%d" for a non-revision entry In order to fix an important bug, we are about to narrow the semantic of "%d" in revset. This is one of the few exceptions that we need to get rid of before being able to fix the bug. See the later semantic narrowing changeset for full rationale on the semantic change.
Thu, 10 Jan 2019 15:57:13 +0100 revset: remove a rare usage of "%d" for a non-revision item
Boris Feld <boris.feld@octobus.net> [Thu, 10 Jan 2019 15:57:13 +0100] rev 41216
revset: remove a rare usage of "%d" for a non-revision item In order to fix an important bug, we are about to narrow the semantic of "%d" in revset. This is one of the few exceptions that we need to get rid of before being able to fix the bug. See the later semantic narrowing changeset for full rationale on the semantic change.
Mon, 14 Jan 2019 17:45:48 -0500 merge with stable
Augie Fackler <augie@google.com> [Mon, 14 Jan 2019 17:45:48 -0500] rev 41215
merge with stable
Sun, 13 Jan 2019 17:56:02 +0530 tests: replace mockmakedate function in test-amend.t
Taapas Agrawal <taapas2897@gmail.com> [Sun, 13 Jan 2019 17:56:02 +0530] rev 41214
tests: replace mockmakedate function in test-amend.t This is a follow up patch for D5554. This replaces mockmakedate function by `tests/mockmakedate.py`. Differential Revision: https://phab.mercurial-scm.org/D5577
Thu, 10 Jan 2019 20:11:19 +0530 histedit: add rewrite.update-timestamp support to fold and mess
Taapas Agrawal <taapas2897@gmail.com> [Thu, 10 Jan 2019 20:11:19 +0530] rev 41213
histedit: add rewrite.update-timestamp support to fold and mess This adds the config option to update time to current in histedit fold and mess options. Setting rewrite.update-timestamp option to `True` will update the timestamp to current time. This also adds `tests/mockmakedate.py` for supplying testable values in case current time is invoked in the tests. Differential Revision: https://phab.mercurial-scm.org/D5554
Sun, 13 Jan 2019 14:46:15 +0900 histedit: remove trailing space from warning message
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Jan 2019 14:46:15 +0900] rev 41212
histedit: remove trailing space from warning message
Sun, 13 Jan 2019 14:44:44 +0900 histedit: fix weird indent of i18n text
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Jan 2019 14:44:44 +0900] rev 41211
histedit: fix weird indent of i18n text
Sun, 13 Jan 2019 14:36:45 +0900 progress: specify updatebar() function by constructor argument
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Jan 2019 14:36:45 +0900] rev 41210
progress: specify updatebar() function by constructor argument This makes it easy for ui extensions to intercept progress messages. It also seems slightly nicer in that scmutil.progress doesn't touch ui internals.
Sun, 13 Jan 2019 14:21:35 +0900 progress: change _updatebar() to take parameters as arguments
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Jan 2019 14:21:35 +0900] rev 41209
progress: change _updatebar() to take parameters as arguments I want to move updatebar() back to ui. See the next patch for why.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip