Fri, 23 Jun 2017 10:59:05 -0700 extensions: call afterloaded() with loaded=False for disabled extensions
Adam Simpkins <simpkins@fb.com> [Fri, 23 Jun 2017 10:59:05 -0700] rev 33014
extensions: call afterloaded() with loaded=False for disabled extensions If an extension was loaded but disabled due to a minimumhgversion check it will be present in the _extensions map, but set to None. The rest of the extensions code treats the extension as if it were not present in this case, but the afterloaded() function called the callback with loaded=True.
Sat, 24 Jun 2017 02:39:13 +0900 fetch: remove shorthand of --edit colliding against -e/-ssh in remoteopts (BC)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 24 Jun 2017 02:39:13 +0900] rev 33013
fetch: remove shorthand of --edit colliding against -e/-ssh in remoteopts (BC) Before this patch, -e/--edit and -e/--ssh of fetch command collide against each other. This causes that -e is treated as shorthand of --edit but doesn't work as same as --edit. Therefore, -e works as neither --edit nor --ssh, in practice. This issue was introduced at 595a69a01129 (or 1.0), which renamed -f/--force-editor to -e/--edit. At that point, -e was already used as shorthand of --ssh. After this patch, -e is treated as shorthand of --ssh. This patch is marked as "(BC)", because -e as shorthand of --edit in existing scripts causes failure (or unexpected result) after this patch. This impact should be less enough, because --edit mainly focuses on interactive use. BTW, test-duplicateoptions.py (since 7d171c05a631 or 1.9) can't detect this kind of issues as expected, because direct invocation of extensions.loadall() doesn't involve registration of commands defined in extensions (this issue is fixed in subsequent patch).
Fri, 23 Jun 2017 17:15:53 +0200 releasenotes: improve parsing around bullet points
Rishabh Madan <rishabhmadan96@gmail.com> [Fri, 23 Jun 2017 17:15:53 +0200] rev 33012
releasenotes: improve parsing around bullet points Earlier, on parsing the bullet points from existing release notes the bullet points after the first one weren't written correctly to the notes file. This patch makes changes to parsereleasenotesfromfile() function that introduces a new bullet_points data structure that tracks the bullets and associated subparagraph. It also makes necessary changes to the tests related to merging of bullets.
Tue, 20 Jun 2017 17:18:20 -0700 bookmarks: factor method _printer out of for loop in printbookmarks
Sean Farley <sean@farley.io> [Tue, 20 Jun 2017 17:18:20 -0700] rev 33011
bookmarks: factor method _printer out of for loop in printbookmarks This allows even further customization via extensions for printing bookmarks. For example, in hg-git this would allow printing remote refs by just modifying the 'bmarks' parameter instead of reimplementing the old commands.bookmarks method. Furthermore, there is another benefit: now multiple extensions can chain their custom data to bookmark printing. Previously, an extension could have conflicting bookmark output due to which loaded first and overrode commands.bookmarks. Now they can all play nicely together.
Tue, 20 Jun 2017 16:36:25 -0700 bookmarks: factor out bookmark printing from commands
Sean Farley <sean@farley.io> [Tue, 20 Jun 2017 16:36:25 -0700] rev 33010
bookmarks: factor out bookmark printing from commands
Tue, 20 Jun 2017 15:56:29 -0700 commands: move activebookmarklabel to bookmarks module
Sean Farley <sean@farley.io> [Tue, 20 Jun 2017 15:56:29 -0700] rev 33009
commands: move activebookmarklabel to bookmarks module This is going to be used in an upcoming patch that moves more methods to bookmarks.py.
Tue, 20 Jun 2017 15:36:43 -0700 commands: replace locking code with a context manager
Sean Farley <sean@farley.io> [Tue, 20 Jun 2017 15:36:43 -0700] rev 33008
commands: replace locking code with a context manager Note that this means that we're unnecessarily creating a transaction in the pure "--inactive" (i.e. when deactivating the current bookmark), but that should be harmless.
Tue, 20 Jun 2017 15:18:40 -0700 bookmarks: factor out adding a list of bookmarks logic from commands
Sean Farley <sean@farley.io> [Tue, 20 Jun 2017 15:18:40 -0700] rev 33007
bookmarks: factor out adding a list of bookmarks logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.
Tue, 13 Jun 2017 11:10:22 -0700 bookmarks: factor out rename logic from commands
Sean Farley <sean@farley.io> [Tue, 13 Jun 2017 11:10:22 -0700] rev 33006
bookmarks: factor out rename logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.
Mon, 12 Jun 2017 23:02:48 -0700 bookmarks: factor out delete logic from commands
Sean Farley <sean@farley.io> [Mon, 12 Jun 2017 23:02:48 -0700] rev 33005
bookmarks: factor out delete logic from commands We keep the lock in the caller so that future devs are aware of the locking implications.
Fri, 23 Jun 2017 15:30:27 -0400 merge with stable
Augie Fackler <augie@google.com> [Fri, 23 Jun 2017 15:30:27 -0400] rev 33004
merge with stable
Sun, 18 Jun 2017 00:40:58 +0900 revset: add startdepth limit to ancestors() as internal option
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 00:40:58 +0900] rev 33003
revset: add startdepth limit to ancestors() as internal option This is necessary to implement the set{gen} (set subscript) operator. For example, set{-n} will be translated to ancestors(set, depth=n, startdepth=n). https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm The UI is undecided and I doubt if the startdepth option would be actually useful, so the option is hidden for now. 'depth' could be extended to take min:max range, in which case, integer depth should select a single generation. ancestors(set, depth=:y) # scan up to y-th generation ancestors(set, depth=x:) # skip until (x-1)-th generation ancestors(set, depth=x) # select only x-th generation Any ideas are welcomed. # reverse(ancestors(tip)) using hg repo 3) 0.075951 4) 0.076175
Sun, 18 Jun 2017 00:22:41 +0900 revset: add depth limit to ancestors()
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 00:22:41 +0900] rev 33002
revset: add depth limit to ancestors() This is proposed by the issue5374, and will be a building block of set{gen} (set subscript) operator. https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm # reverse(ancestors(tip)) using hg repo 2) 0.075408 3) 0.075951
Sun, 18 Jun 2017 00:11:48 +0900 dagop: compute depth in revancestors() generator
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 00:11:48 +0900] rev 33001
dagop: compute depth in revancestors() generator Surprisingly, this makes revset benchmark slightly faster. I don't know why, but it appears that wrapping -inputrev by tuple is the key. So I decided to just enable depth computation by default. # reverse(ancestors(tip)) using hg repo 1) 0.081051 2) 0.075408
Sun, 18 Jun 2017 08:59:09 +0900 dagop: just compare with the last value to deduplicate input of revancestors()
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 08:59:09 +0900] rev 33000
dagop: just compare with the last value to deduplicate input of revancestors() Since we're using a max heap, the current rev should be a duplicate only if it equals to the previous one. We don't have to maintain the whole seen set. # reverse(ancestors(tip)) using hg repo 0) 0.086420 1) 0.081051
Sun, 18 Jun 2017 17:22:57 +0900 dagop: bulk rename variables in revancestors() generator
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 17:22:57 +0900] rev 32999
dagop: bulk rename variables in revancestors() generator - h -> pendingheap: "h" seems too short for variable of long lifetime - current -> currev: future patches will add current "depth" variable - parent -> prev or pctx: short lifetime, follows common naming rules
Sun, 18 Jun 2017 17:16:02 +0900 dagop: comment why revancestors() doesn't heapify input revs at once
Yuya Nishihara <yuya@tcha.org> [Sun, 18 Jun 2017 17:16:02 +0900] rev 32998
dagop: comment why revancestors() doesn't heapify input revs at once I wondered why we're doing this complicated stuff without noticing the input revs may be iterated lazily in descending order. c1f666e27345 showed why.
Sat, 17 Jun 2017 22:33:23 +0900 dagop: unnest inner generator of revancestors()
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Jun 2017 22:33:23 +0900] rev 32997
dagop: unnest inner generator of revancestors() This just moves iterate() to module-level function.
Wed, 21 Jun 2017 17:17:17 +0200 hgweb: plug followlines action in annotate view
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:17:17 +0200] rev 32996
hgweb: plug followlines action in annotate view Add the followlines.js script and corresponding parameters as data attribute on <tbody class="sourcelines"> element. Extend CSS rules so that they also match the DOM structure of annotate view. As previously, only address paper and gitweb styles (other styles do not have followlines at all).
Wed, 21 Jun 2017 17:07:51 +0200 hgweb: parameterize the tag name of elements holding followlines selection
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:07:51 +0200] rev 32995
hgweb: parameterize the tag name of elements holding followlines selection While plugging followlines.js into "annotate" view, we'll need to walk a different DOM structure from that of "filerevision" view. In particular, the selectable source line element is a <tr> in annotate view (in contrast with a <span> in filerevision view). So make this tag name a parameter of followlines.js script by passing its value as a "selectabletag" data attribute of <pre class="sourcelines"> element. As <pre class="sourcelines"> tags are getting quite long in templates, rewrite them on several lines.
Wed, 21 Jun 2017 17:02:21 +0200 gitweb: wrap table rows of annotate view into a <tbody> element
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 21 Jun 2017 17:02:21 +0200] rev 32994
gitweb: wrap table rows of annotate view into a <tbody> element We will use this element to hook data attribute for the followlines.js script to be plugged in annotate view. Also this gets symmetrical with paper style which already has a <tbody> element.
Thu, 22 Jun 2017 11:16:29 +0200 tests: update regex check for fetch error in test-clonebundles.t
Denis Laxalde <denis@laxalde.org> [Thu, 22 Jun 2017 11:16:29 +0200] rev 32993
tests: update regex check for fetch error in test-clonebundles.t On some systems, e.g. Docker container, the actual error may be: error fetching bundle: [Errno 99] Cannot assign requested address Update the regex to handle this case.
Tue, 20 Jun 2017 20:53:29 -0700 hgweb: use separate CSS class for navigation links in footer
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 20 Jun 2017 20:53:29 -0700] rev 32992
hgweb: use separate CSS class for navigation links in footer 2d93d2159e30 changed the styling of the "page_nav" CSS class to use flexbox to separate elements within the <div>. I didn't realize that this class was used outside of the links in the header. So this resulted in incorrectly formatting links in the footer of various pages. Fix that by introducing a new CSS class that preserves the old CSS behavior.
Sat, 17 Jun 2017 13:25:42 +0200 configitems: register 'ui.clonebundleprefers' as example for 'configlist'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 13:25:42 +0200] rev 32991
configitems: register 'ui.clonebundleprefers' as example for 'configlist' This exercise the default value handling in 'configlist'.
Sat, 17 Jun 2017 13:17:10 +0200 configitems: register 'patch.fuzz' as first example for 'configint'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 13:17:10 +0200] rev 32990
configitems: register 'patch.fuzz' as first example for 'configint' This exercise the default value handling in 'configint'.
Sat, 17 Jun 2017 13:08:03 +0200 configitems: issue a devel warning when overriding default config
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 13:08:03 +0200] rev 32989
configitems: issue a devel warning when overriding default config If the option is registered, there is already a default value available and passing a new one is at best redundant. So we issue a deprecation warning in this case. (note: there will be case were the default value will not be as simple as what is currently possible. We'll upgrade the configitems code to handle them in time.)
Fri, 23 Jun 2017 13:22:04 +0200 eol: fix 'error' parameter name in the commitctx wrapper stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Jun 2017 13:22:04 +0200] rev 32988
eol: fix 'error' parameter name in the commitctx wrapper Since its introduction in 9dfee83c93c8, the parameter has always been name "error". Yet the eol extension have been using 'haserror' as the argument name, breaking extensions with subclass passing 'error' as a keyword argument.
Fri, 23 Jun 2017 13:24:45 +0200 eol: import 'error' as 'errormod' stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Jun 2017 13:24:45 +0200] rev 32987
eol: import 'error' as 'errormod' We need the 'error' name available to fix another bug, so we rename the imported module.
Sat, 17 Jun 2017 12:33:59 +0200 configitems: register 'ui.quiet' as first example
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:33:59 +0200] rev 32986
configitems: register 'ui.quiet' as first example We now have a user and this works fine.
Sat, 17 Jun 2017 12:15:28 +0200 configitems: get default values from the central registry when available
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:15:28 +0200] rev 32985
configitems: get default values from the central registry when available We do not have any registered config yet, but we are now ready to use them. For now we ignore this feature for config access with "alternates". On the long run, we expect alternates to be handled as "aliases" by the config item themself.
Sat, 17 Jun 2017 18:43:27 +0200 configitems: introduce a central registry for config option
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 18:43:27 +0200] rev 32984
configitems: introduce a central registry for config option We now have the appropriate infrastructure to register config items. Usage will added in the next changeset.
Sat, 17 Jun 2017 18:41:55 +0200 configitems: add a basic class to hold config item information
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 18:41:55 +0200] rev 32983
configitems: add a basic class to hold config item information The goal of this class is allow explicit declaration for the available config option. This class will hold the data for one specific config item. To keep it simple we start centralizing the handling of the default config value. In the future we can expect more data to be carried on this class. For example: - documentation, - status (experimental, advanced, normal, deprecated), - aliases, - expected type, - etc...
Wed, 21 Jun 2017 01:12:31 -0700 run-tests: fix -i when "#testcases" is used in .t test
Jun Wu <quark@fb.com> [Wed, 21 Jun 2017 01:12:31 -0700] rev 32982
run-tests: fix -i when "#testcases" is used in .t test The "#testcases" feature introduced by 7340465bd788 has issues with "-i" because "-i" uses "test.name.endswith('.t')" to test if a test is .t or not. test.name could now be something like "test-foo.t (caseA)" so the above endswith test is no longer valid. This patch changes the test to use "self.path" which won't have the issue.
Wed, 21 Jun 2017 01:12:31 -0700 run-tests: update .t reference output after reading the test
Jun Wu <quark@fb.com> [Wed, 21 Jun 2017 01:12:31 -0700] rev 32981
run-tests: update .t reference output after reading the test The .t file is both test input and reference output. They should always match. However we have different code paths to read reference output (Test.__init__ -> Test.readrefout) and test input (TTest._run) so they might be inconsistent if somethings change the file between those two functions. This patch assigns "lines" read by "_run" back to "_refout" if "_refout" is not None (with --debug, see Test.readrefout) so reference output and test input will always match.
Wed, 21 Jun 2017 01:05:20 -0700 run-tests: do not prompt changes (-i) if a race condition is detected
Jun Wu <quark@fb.com> [Wed, 21 Jun 2017 01:05:20 -0700] rev 32980
run-tests: do not prompt changes (-i) if a race condition is detected The race condition is like: 1. run-tests.py reads test-a.t as reference output, content A 2. run-tests.py runs the test (which could be content B, another race condition fixed by the next patch, but assume it's content A here) 3. something changes test-a.t to content C 4. run-tests.py compares test output (content D) with content A 5. with "-i", run-tests.py prompts diff(A, D), while the file has content C instead of A at this time This patch detects the above case and tell the user to rerun the test if they want to apply test changes.
Tue, 20 Jun 2017 23:22:38 -0700 patch: rewrite reversehunks (issue5337)
Jun Wu <quark@fb.com> [Tue, 20 Jun 2017 23:22:38 -0700] rev 32979
patch: rewrite reversehunks (issue5337) The old reversehunks code accesses "crecord.uihunk._hunk", which is the raw recordhunk without crecord selection information, therefore "revert -i" cannot revert individual lines, aka. issue5337. The patch rewrites related logic to return the right reverse hunk for revert. Namely, 1. "fromline" and "toline" are correctly swapped [1] 2. crecord.uihunk generates a correct reverse hunk [2] Besides, reversehunks(hunks) will no longer modify its input "hunks", which is more expected. [1]: To explain why "fromline" and "toline" need to be swapped, take the following example: $ cat > a <<EOF > 1 > 2 > 3 > 4 > EOF $ cat > b <<EOF > 2 > 3 > 5 > EOF $ diff a b 1d0 <---- "1" is "fromline" and "0" is "toline" < 1 and they are swapped if diff from the reversed direction 4c3 | < 4 | --- | > 5 | | $ diff b a | 0a1 <---------+ > 1 3c4 <---- also "4c3" gets swapped to "3c4" < 5 --- > 4 [2]: This is a bit tricky. For example, given a file which is empty in working parent but has 3 lines in working copy, and the user selection: select hunk to discard [x] +1 [ ] +2 [x] +3 The user intent is to drop "1" and "3" in working copy but keep "2", so the reverse patch would be something like: -1 2 (2 is a "context line") -3 We cannot just take all selected lines and swap "-" and "+", which will be: -1 -3 That patch won't apply because of "2". So the correct way is to insert "2" as a "context line" by inserting it first then deleting it: -2 +2 Therefore, the correct revert patch is: -1 -2 +2 -3 It could be reordered to look more like a common diff hunk: -1 -2 -3 +2 Note: It's possible to return multiple hunks so there won't be lines like "-2", "+2". But the current implementation is much simpler. For deletions, like the working parent has "1\n2\n3\n" and it was changed to empty in working copy: select hunk to discard [x] -1 [ ] -2 [x] -3 The user intent is to drop the deletion of 1 and 3 (in other words, keep those lines), but still delete "2". The reverse patch is meant to be applied to working copy which is empty. So the patch would be: +1 +3 That is to say, there is no need to special handle the unselected "2" like the above insertion case.
Wed, 21 Jun 2017 10:46:18 +0200 profiling: cope with configwith default value handling changes
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Jun 2017 10:46:18 +0200] rev 32978
profiling: cope with configwith default value handling changes Changeset 6ff6eb33f353 change 'configwith' behavior so that the default value is run through the conversion function. In parallel a new user of 'configwith' got introduced unaware of this coming behavior change. This broke profiling. We resolve the situation by having the new conversion function cope with a default value already using the right type.
Tue, 20 Jun 2017 14:00:41 -0700 py3: catch StopIteration from next() in generatorset
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Jun 2017 14:00:41 -0700] rev 32977
py3: catch StopIteration from next() in generatorset IIUC, letting the StopIteration through would not cause any bugs, but not doing it makes the test-py3-commands.t pass. I have also diligently gone through all uses of next() in our code base. They either: * are not called from a generator * pass a default value to next() * catch StopException * work on infinite iterators * request a fixed number of items that matches the generated number * are about batching in wireproto which I didn't quite follow I'd appreciate if Augie or someone else could take a look at the wireproto batching and convince themselves that the next(batchable) calls there will not raise a StopIteration.
Tue, 20 Jun 2017 23:23:45 -0400 tests: adjust quoting to keep Windows happy with recent $PYTHON change
Matt Harbison <matt_harbison@yahoo.com> [Tue, 20 Jun 2017 23:23:45 -0400] rev 32976
tests: adjust quoting to keep Windows happy with recent $PYTHON change I tried adding quotes to the $PYTHON variable, and also tried converting the path from the current 'c:/Python/python.exe' form to '/c/python/python.exe', but neither worked. I'm not sure why one of these needs '\"' around the variable and the other doesn't.
Tue, 20 Jun 2017 16:33:13 -0700 bundle2: don't use debug message "no-transaction" with transaction
Martin von Zweigbergk <martinvonz@google.com> [Tue, 20 Jun 2017 16:33:13 -0700] rev 32975
bundle2: don't use debug message "no-transaction" with transaction
Wed, 21 Jun 2017 02:20:34 +0530 py3: use pycompat.bytestr() in place of str()
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Jun 2017 02:20:34 +0530] rev 32974
py3: use pycompat.bytestr() in place of str()
Wed, 21 Jun 2017 02:13:34 +0530 py3: use r'' to access values from kwargs where keys are str
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Jun 2017 02:13:34 +0530] rev 32973
py3: use r'' to access values from kwargs where keys are str These are the cases where either args is again passed as keyword argument or 1 or 2 elements are accessed. So it's better to add an r'' to prevent it converting to bytes rather than doing the conversion of args.
Wed, 21 Jun 2017 02:10:25 +0530 py3: convert keys of kwargs in template keywords functions to bytes
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 21 Jun 2017 02:10:25 +0530] rev 32972
py3: convert keys of kwargs in template keywords functions to bytes This patch converts the args argument keys' to bytes wherever necessary as there are some places where either args is not used or using r'' is better or args is again passed as keyword arguments.
Tue, 20 Jun 2017 23:50:50 +0530 py3: make sure the commands name are bytes in test-devel-warnings.t
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 23:50:50 +0530] rev 32971
py3: make sure the commands name are bytes in test-devel-warnings.t
Tue, 20 Jun 2017 23:46:18 +0530 py3: replace str with bytes in isinstance()
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 23:46:18 +0530] rev 32970
py3: replace str with bytes in isinstance() We were using str because on Python 2, str were bytes but now we have to use bytes. Otherwise the if conditions fails and we have weird results from commands on Python 3.
Tue, 20 Jun 2017 22:11:46 +0530 py3: catch binascii.Error raised from binascii.unhexlify
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 20 Jun 2017 22:11:46 +0530] rev 32969
py3: catch binascii.Error raised from binascii.unhexlify Before Python 3, binsacii.unhexlify used to raise TypeError, now it raises binascii.Error.
Tue, 20 Jun 2017 23:39:59 -0700 shelve: allow unlimited shelved changes per name
Jun Wu <quark@fb.com> [Tue, 20 Jun 2017 23:39:59 -0700] rev 32968
shelve: allow unlimited shelved changes per name Previously, there is a 100 changes limit per name (bookmark or named branch). And the user will get "too many shelved changes named %s" when they are trying to shelve the 101th change. I hit that error message today. This limit was introduced by the shelve extension since the beginning. The function generating the names was called "gennames", under "getshelvename". There is another "gennames" under "backupfilename": def backupfilename(self): def gennames(base): yield base base, ext = base.rsplit('.', 1) for i in itertools.count(1): yield '%s-%d.%s' % (base, i, ext) "itertools.count" is an endless counter. Since the other "gennames" generates unlimited number of names, and the changeset introducing the limit (49d4919d21) does not say why the limit is useful. It seems safe to just remove the limit. The format "%02d" was kept intentionally so existing shelved changes won't break.
Sat, 17 Jun 2017 12:51:37 +0200 config: use the new '_unset' value for 'configsuboptions'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:51:37 +0200] rev 32967
config: use the new '_unset' value for 'configsuboptions' This should let configsuboptions delegate all special processing of the default config value to the main 'config' method.
Sat, 17 Jun 2017 18:28:20 +0200 config: use the 'config' method in 'configsuboptions'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 18:28:20 +0200] rev 32966
config: use the 'config' method in 'configsuboptions' There was unnecessary code duplication. It was getting in the way of the unification of the default value logic.
Sat, 17 Jun 2017 12:52:02 +0200 config: use the new '_unset' value for 'configpath'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:02 +0200] rev 32965
config: use the new '_unset' value for 'configpath' This should let 'configpath' delegate all special processing of the default config value to the main 'config' method.
Sat, 17 Jun 2017 12:54:45 +0200 config: use the new '_unset' value for 'configdate'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:54:45 +0200] rev 32964
config: use the new '_unset' value for 'configdate' This should let 'configdate' delegate all special processing of the default config value to the main 'config' method. The default value for date (None) is still enforced in this method if no other default were passed.
Sat, 17 Jun 2017 12:54:04 +0200 config: use the new '_unset' value for 'configlist'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:54:04 +0200] rev 32963
config: use the new '_unset' value for 'configlist' This should let 'configlist' delegate all special processing of the default config value to the main 'config' method. The default config value ([]) is still handled in this method.
Sat, 17 Jun 2017 12:53:51 +0200 config: use the new '_unset' value for 'configbytes'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:51 +0200] rev 32962
config: use the new '_unset' value for 'configbytes' This should let 'configbytes' delegates all special processing of the default config value to the main 'config' method.
Sat, 17 Jun 2017 12:53:40 +0200 config: use the new '_unset' value for 'configint'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:53:40 +0200] rev 32961
config: use the new '_unset' value for 'configint' This should let 'configint' delegates all special processing of the default config value to the main 'config' method.
Sat, 17 Jun 2017 12:52:31 +0200 config: use the new '_unset' value for 'configwith'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:31 +0200] rev 32960
config: use the new '_unset' value for 'configwith' This should let 'configwith' delegate all special processing of the default config value to the main 'config' method. This changeset introduce a small change in behavior since the default value is run through the 'convert' function. This does not seems harmful and no actual test break. This small change make the code simpler so I'm keeping it.
Sat, 17 Jun 2017 12:52:16 +0200 config: use the new '_unset' value for 'configbool'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:52:16 +0200] rev 32959
config: use the new '_unset' value for 'configbool' This should let 'configbool' delegate all special processing of the default config value to the main 'config' method. The default value for bool (False) is still enforced in this method if no other default were passed.
Sat, 17 Jun 2017 12:51:11 +0200 config: explicitly track the use of the standard default value
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 17 Jun 2017 12:51:11 +0200] rev 32958
config: explicitly track the use of the standard default value We introduce a small object used to detect that no specific default value has been passed to 'ui.config'. We need this explicit special value since "None" is a valid and common default value. The end goal here is to make progress on a centralised and explicit declaration of the available config option. A first good usecase for this are "default" value. Before starting looking further down this alley we needs to rework the handling of default value in the 'ui' object to have all configxyz methods going through the same logic. This is the first changeset on this trek.
Mon, 19 Jun 2017 22:14:37 -0700 clonebundle: update hook arguments (BC)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Jun 2017 22:14:37 -0700] rev 32957
clonebundle: update hook arguments (BC) By calling applybundle() with 'clonebundles' and the url instead of calling processbundle(), the hooks will get different arguments: HG_SOURCE will be 'clonebundles' instead of 'bundle2' and HG_URL will be the url instead of 'bundle2'. This is consistent with the bundle1 behavior and seems like a bug fix, but I'm marking it BC anyway.
Sat, 10 Jun 2017 23:42:38 -0700 commands: move checkconflict to bookmarks module
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 23:42:38 -0700] rev 32956
commands: move checkconflict to bookmarks module Again, commands.bookmark is getting too large. checkconflict already has a lot of state and putting it in the bmstore makes more sense than having it as a closure. This also allows extensions a place to override this behavior. While we're here, add a documentation string because, well, we should be documenting more of our methods.
Sat, 10 Jun 2017 23:32:58 -0700 commands: move checkformat to bookmarks module
Sean Farley <sean@farley.io> [Sat, 10 Jun 2017 23:32:58 -0700] rev 32955
commands: move checkformat to bookmarks module commands.bookmark has grown quite large with two closures already. Let's split this up (and in the process allow extensions to override the default behavior).
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip