Thu, 02 Aug 2018 12:18:35 -0700 changegroup: move generatefiles() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 12:18:35 -0700] rev 38889
changegroup: move generatefiles() from narrow The code is a bit ugly in that it overrides the linknodes function that is passed in as a function. I'd like to think that the caller of generatefiles() would pass in the appropriate function. We can clean this up later. Differential Revision: https://phab.mercurial-scm.org/D4066
Thu, 02 Aug 2018 12:12:12 -0700 changegroup: move _sortgroup() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 12:12:12 -0700] rev 38888
changegroup: move _sortgroup() from narrow Differential Revision: https://phab.mercurial-scm.org/D4065
Thu, 02 Aug 2018 09:52:01 -0700 changegroup: move close() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:52:01 -0700] rev 38887
changegroup: move close() from narrow More of the same. Differential Revision: https://phab.mercurial-scm.org/D4064
Thu, 02 Aug 2018 09:53:22 -0700 changegroup: move revchunk() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:53:22 -0700] rev 38886
changegroup: move revchunk() from narrow The monkeypatched revchunk for ellipses serving is a completely independent implementation. We model it as such in the changegroup code. revchunk() is now a simple proxy function. Again, I wish we had better APIs here. Especially since this narrow code is part of cg1packer and cg1packer can't be used with narrow. Class inheritance is wonky. And I will definitely be making changes to changegroup code for delta generation. As part of the code move, `node.nullrev` was replaced by `nullrev`. And a reference to `orig` was replaced to call `self._revchunknormal` directly. Differential Revision: https://phab.mercurial-scm.org/D4063
Thu, 02 Aug 2018 09:40:18 -0700 changegroup: move deltaparent() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 02 Aug 2018 09:40:18 -0700] rev 38885
changegroup: move deltaparent() from narrow I'm not keen on performing the attribute sniff to test for presence of ellipses mode: I'd rather we use a separate packer instance that was ellipses mode specific. But I've tried to formalize a better API without narrow in core and I can't make sense of all the monkeypatching. My goal is to inline as much of the monkeypatching as possible then refactor the changegroup generation API. We add this code to the cg2packer because narrow doesn't work with cg1. Differential Revision: https://phab.mercurial-scm.org/D4062
Sat, 28 Jul 2018 17:59:37 -0700 changegroup: move _packellipsischangegroup() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 Jul 2018 17:59:37 -0700] rev 38884
changegroup: move _packellipsischangegroup() from narrow The behavior here is not ideal, as the function constructs a packer then adds attributes to it. This will be cleaned up in subsequent commits. Moving this code is necessary to move the remainder of the bundle2-level changegroup part generation code into core. Differential Revision: https://phab.mercurial-scm.org/D4061
Sat, 28 Jul 2018 17:52:21 -0700 changegroup: move ellipsisdata() from narrow
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 Jul 2018 17:52:21 -0700] rev 38883
changegroup: move ellipsisdata() from narrow This is a pretty straightforward copy of the function. Differential Revision: https://phab.mercurial-scm.org/D4060
Sun, 22 Jul 2018 19:48:50 +0900 fileset: narrow status computation by left-hand-side of 'and' node
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 19:48:50 +0900] rev 38882
fileset: narrow status computation by left-hand-side of 'and' node Timing with warm disk cache: $ hg status --cwd mozilla-central 'set:path:build/ and unknown()' --time (orig) time: real 1.970 secs (user 1.560+0.000 sys 0.410+0.000) (new) time: real 0.330 secs (user 0.310+0.000 sys 0.020+0.000)
Sun, 22 Jul 2018 19:43:57 +0900 fileset: move copy constructor of matchctx near __init__
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 19:43:57 +0900] rev 38881
fileset: move copy constructor of matchctx near __init__
Sun, 22 Jul 2018 11:20:48 +0900 fileset: build status according to 'withstatus' hint
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 11:20:48 +0900] rev 38880
fileset: build status according to 'withstatus' hint _switchcallers is no longer needed since 'withstatus' node is reinserted for arguments of functions like revs(). New matchctx instance is created per 'withstatus' to make sure that status tuple is available only for children of the 'withstatus' node.
Sat, 21 Jul 2018 20:27:53 +0900 fileset: insert hints where status should be computed
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Jul 2018 20:27:53 +0900] rev 38879
fileset: insert hints where status should be computed This will allow us to compute status against a narrowed set of files. For example, "path:build/ & (unknown() + missing())" is rewritten as "path:build/ & <withstatus>(unknown() + missing(), 'unknown missing')", and the status call can be narrowed by the left-hand-side matcher, "path:build/". mctx.buildstatus() calls will be solely processed by getmatchwithstatus().
Sun, 22 Jul 2018 11:12:55 +0900 fileset: move buildstatus() to matchctx method
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 11:12:55 +0900] rev 38878
fileset: move buildstatus() to matchctx method In future patches, file status will be computed while evaluating a parsed tree. This patch provides a matchctx interface to build status.
Sun, 22 Jul 2018 10:58:32 +0900 fileset: keep basectx by matchctx
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 10:58:32 +0900] rev 38877
fileset: keep basectx by matchctx
Sun, 22 Jul 2018 10:55:38 +0900 fileset: pass in basectx to _buildstatus()
Yuya Nishihara <yuya@tcha.org> [Sun, 22 Jul 2018 10:55:38 +0900] rev 38876
fileset: pass in basectx to _buildstatus() I'll make matchctx remember both ctx and basectx so that file status between them can be computed later. This prepares for the change.
Sat, 04 Aug 2018 12:58:08 +0530 resolve: update commands.resolve.confirm help text
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 04 Aug 2018 12:58:08 +0530] rev 38875
resolve: update commands.resolve.confirm help text Included --mark and --unmark in the help text of resolve.confirm.config. Differential Revision: https://phab.mercurial-scm.org/D4103
Sat, 04 Aug 2018 12:43:41 +0530 resolve: support confirm config option with --unmark flag
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 04 Aug 2018 12:43:41 +0530] rev 38874
resolve: support confirm config option with --unmark flag Now, commands.resolve.confirm also respect --unmark option; and confirm to unresolve all resolved files. It will confirm only when no files pats are passed (same as --mark), because when no pats are passed the default is to mark resolved files as unresolved. And if user has passed file pats then I think there is no need to confirm for that. Differential Revision: https://phab.mercurial-scm.org/D4102
Sun, 05 Aug 2018 00:53:55 -0700 resolve: correct behavior of mark-check=none to match docs
Kyle Lippincott <spectral@google.com> [Sun, 05 Aug 2018 00:53:55 -0700] rev 38873
resolve: correct behavior of mark-check=none to match docs Differential Revision: https://phab.mercurial-scm.org/D4121
Thu, 02 Aug 2018 14:57:20 -0700 narrow: move .hg/narrowspec to .hg/store/narrowspec (BC)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 Aug 2018 14:57:20 -0700] rev 38872
narrow: move .hg/narrowspec to .hg/store/narrowspec (BC) The narrowspec is more closely related to the store than to the working copy. For example, if the narrowspec changes, the set of revlogs also needs to change (the working copy may change, but that depends on which commit is checked out). Also, when using the share extension, the narrowspec needs to be shared along with the store. This patch therefore moves the narrowspec into the store/ directory. This is clearly a breaking change, but I haven't bothered trying to fall back to reading the narrowspec from the old location (.hg/), because there are very few users of narrow out there. (We'll add a temporary hack to our Google-internal extension to handle the migration.) Differential Revision: https://phab.mercurial-scm.org/D4099
Fri, 03 Aug 2018 13:53:02 -0700 narrow: drop checkambig=True when restoring backup
Martin von Zweigbergk <martinvonz@google.com> [Fri, 03 Aug 2018 13:53:02 -0700] rev 38871
narrow: drop checkambig=True when restoring backup IIUC, checkambig is about updating timestamps of the file while renaming. That's important for the dirstate, but we never check the timestamp of the narrowspec file. We can therefore avoid checking passing checkambig=True. Differential Revision: https://phab.mercurial-scm.org/D4098
Thu, 02 Aug 2018 14:30:40 -0700 narrow: remove a repo file-cache invalidation
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 Aug 2018 14:30:40 -0700] rev 38870
narrow: remove a repo file-cache invalidation It's unclear why this was needed. All tests pass without it. I asked Kyle Lippincott (who added the check) and he also doesn't remember what it was for. Differential Revision: https://phab.mercurial-scm.org/D4097
Fri, 03 Aug 2018 11:09:41 -0700 narrow: call narrowspec.{save,restore,clear}backup directly
Martin von Zweigbergk <martinvonz@google.com> [Fri, 03 Aug 2018 11:09:41 -0700] rev 38869
narrow: call narrowspec.{save,restore,clear}backup directly I want to move .hg/narrowspec to .hg/store/narrowspec and we need to decouple the narrowspec update from the dirstate update for that. This patch lets the callers call the narrowspec backup functions directly, in addition to the dirstate backup functions. The narrowspec methods are made to check if narrowing is enabled. For that, a repo instance was needed, which all the callers luckily already had available. Differential Revision: https://phab.mercurial-scm.org/D4096
Sat, 04 Aug 2018 23:15:06 -0700 index: don't add 1 to length variables
Martin von Zweigbergk <martinvonz@google.com> [Sat, 04 Aug 2018 23:15:06 -0700] rev 38868
index: don't add 1 to length variables A lot of "+ 1" and "-1" were mechanically added to ease the transition in 781b2720d2ac (index: don't include nullid in len(), 2018-07-20). Let's clean it up now. Differential Revision: https://phab.mercurial-scm.org/D4106
Sat, 04 Aug 2018 22:48:25 -0700 index: drop support for nullid at position len(index) in index_node
Martin von Zweigbergk <martinvonz@google.com> [Sat, 04 Aug 2018 22:48:25 -0700] rev 38867
index: drop support for nullid at position len(index) in index_node I think no callers exist since at least a3dacabd476b (index: don't allow index[len(index)] to mean nullid, 2018-07-20). Differential Revision: https://phab.mercurial-scm.org/D4105
Sat, 04 Aug 2018 23:15:03 -0700 index: return False for "len(index) in index"
Martin von Zweigbergk <martinvonz@google.com> [Sat, 04 Aug 2018 23:15:03 -0700] rev 38866
index: return False for "len(index) in index" Since we no longer accept index[len(index)], we should clearly make "len(index) in index" return False. This should have been part of a3dacabd476b (index: don't allow index[len(index)] to mean nullid, 2018-07-20) Differential Revision: https://phab.mercurial-scm.org/D4104
Sat, 21 Jul 2018 17:19:12 +0900 fileset: combine union of basic patterns into single matcher
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Jul 2018 17:19:12 +0900] rev 38865
fileset: combine union of basic patterns into single matcher This appears to improve query performance in a big repository than I thought. Writing less Python in a hot loop, faster computation we gain. $ hg files --cwd mozilla-central --time 'set:a* + b* + c* + d* + e*' (orig) time: real 0.670 secs (user 0.640+0.000 sys 0.030+0.000) (new) time: real 0.210 secs (user 0.180+0.000 sys 0.020+0.000)
Sat, 21 Jul 2018 17:13:34 +0900 fileset: reorder 'or' expression by weight
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Jul 2018 17:13:34 +0900] rev 38864
fileset: reorder 'or' expression by weight
Sat, 04 Aug 2018 17:08:33 +0900 fileset: introduce weight constants for readability
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Aug 2018 17:08:33 +0900] rev 38863
fileset: introduce weight constants for readability These constants are defined in the filesetlang module since it's the bottommost module depending on WEIGHT_CHECK_FILENAME, and extensions will be likely to import it to process function arguments. Credit for the naming goes to Augie Fackler.
Sat, 04 Aug 2018 17:17:31 +0900 sparse: use named parameters in i18n strings
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Aug 2018 17:17:31 +0900] rev 38862
sparse: use named parameters in i18n strings This should give more hints about what the %s means, and allow reordering.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip