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.
Sat, 04 Aug 2018 17:11:03 +0900 sparse: do not include operator in i18n strings
Yuya Nishihara <yuya@tcha.org> [Sat, 04 Aug 2018 17:11:03 +0900] rev 38861
sparse: do not include operator in i18n strings
Fri, 03 Aug 2018 16:39:09 -0700 fix: compute changed lines lazily to make whole-file fixer tools faster
Danny Hooper <hooper@google.com> [Fri, 03 Aug 2018 16:39:09 -0700] rev 38860
fix: compute changed lines lazily to make whole-file fixer tools faster Differential Revision: https://phab.mercurial-scm.org/D4100
Sat, 04 Aug 2018 12:23:18 +0530 resolve: support commands.resolve.confirm option with --mark flag
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 04 Aug 2018 12:23:18 +0530] rev 38859
resolve: support commands.resolve.confirm option with --mark flag Now, commands.resolve.confirm config option also respect --mark; and confirm to mark all 'unresolved' files as 'resolved'. It will confirm only when you don't pass any pats i.e 'hg resolve -m', because when no file pats are passed then --mark's default functionality is to mark all unresolved files. And if user has given file pats then I think there is no need to confirm. Differential Revision: https://phab.mercurial-scm.org/D4101
Fri, 03 Aug 2018 12:59:01 -0700 resolve: add commands.resolve.mark-check=abort to tweakdefaults
Kyle Lippincott <spectral@google.com> [Fri, 03 Aug 2018 12:59:01 -0700] rev 38858
resolve: add commands.resolve.mark-check=abort to tweakdefaults Differential Revision: https://phab.mercurial-scm.org/D4072
Fri, 03 Aug 2018 12:57:44 -0700 resolve: graduate resolve.mark-check from experimental, add docs
Kyle Lippincott <spectral@google.com> [Fri, 03 Aug 2018 12:57:44 -0700] rev 38857
resolve: graduate resolve.mark-check from experimental, add docs Since this hasn't been in a release yet, I'm not bothering to add an alias for the experimental name of the config variable. Differential Revision: https://phab.mercurial-scm.org/D4071
Mon, 16 Apr 2018 23:49:38 -0700 shortest: use 'x' prefix to disambiguate from revnum if configured
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Apr 2018 23:49:38 -0700] rev 38856
shortest: use 'x' prefix to disambiguate from revnum if configured Differential Revision: https://phab.mercurial-scm.org/D4042
Sun, 29 Apr 2018 10:07:40 -0700 revisions: allow "x123" to refer to nodeid prefix "123"
Martin von Zweigbergk <martinvonz@google.com> [Sun, 29 Apr 2018 10:07:40 -0700] rev 38855
revisions: allow "x123" to refer to nodeid prefix "123" When resolving "123" to a revision, we try to interpret it as revnum before we try to interpret it as a nodeid hex prefix. This can lead to the shortest valid prefix being longer than necessary. This patch lets us write such nodeids in a shorter form by prefixing them with "x" instead of adding more hex digits until they're longer than the longest decimal revnum. On my hg repo with almost 69k revisions, turning this feature on saves on average 0.4% on the average nodeid length. That clearly doesn't justify this patch. However, it becomes more usefule when combined with the earlier patches in this series that let you disambiguate nodeid prefixes within a configured revset. Note that we attempt to resolve symbols as nodeid prefixes after we've exhausted all other posibilities, so this is a backwards compatible change (only queries that would previously fail may now succeed). I've still hidden this feature behind an experiemntal config option so we can roll it back if needed. Differential Revision: https://phab.mercurial-scm.org/D4041
Mon, 07 May 2018 16:12:12 -0700 shortest: make isrev() a top-level function
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 May 2018 16:12:12 -0700] rev 38854
shortest: make isrev() a top-level function I'm going to add another caller in the next patch. Differential Revision: https://phab.mercurial-scm.org/D4040
Tue, 17 Apr 2018 11:16:59 -0700 shortest: cache disambiguation revset
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Apr 2018 11:16:59 -0700] rev 38853
shortest: cache disambiguation revset This makes it actually useful. In compared the time in my hg repo with 69.6k revisions and with a disambiguation revset of "not public()" that matches 563 visible revisions. I ran "time hg log -T '{shortest(node1,)}' -r 0:1000" (no revisions within the revset in that revision range). Before this patch, it took 57s and after it took 0.7s. Differential Revision: https://phab.mercurial-scm.org/D4039
Fri, 20 Jul 2018 14:36:42 -0700 index: don't allow index[len(index)] to mean nullid
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Jul 2018 14:36:42 -0700] rev 38852
index: don't allow index[len(index)] to mean nullid Now everything else has been cleaned up and we can drop support for getting the nullid from the end of the index (from *past* the end actually, since we reduced the length in the previous patch). Differential Revision: https://phab.mercurial-scm.org/D4023
Fri, 20 Jul 2018 08:10:32 -0700 index: don't include nullid in len()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Jul 2018 08:10:32 -0700] rev 38851
index: don't include nullid in len() I suspect the reason the nullid is in the index in the last position is that it lets index[i] for regular revision number, even when index was just a regular Python list. An alternative solution would have been to reserve revision number 0 for the null revision. I don't know why that wasn't done. Now that we have classes backing the index, we can easily make index[-1] get the nullid without having to put it last in the list and including it in the len(). This patch just hides the nullid -- it will still be accessible at index[len(index)]. I realize that this will be annoying when checking out across this commit for debugging (including bisection). Differential Revision: https://phab.mercurial-scm.org/D4022
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip