Fri, 12 Sep 2014 02:29:19 +0900 mq: examine "pushable" of already applied patch correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22456
mq: examine "pushable" of already applied patch correctly Before this patch, "hg qselect" with --pop/--reapply may pop patches unexpectedly, even when all of patches applied before "qselect" are still pushable. Strictly speaking about the condition of this issue: - before "qselect" - there are N applied patches - the index of the guarded patch X in the series is less than N - after "qselect" - X is still guarded, and - all of applied patched are still pushable In the case above, "hg qselect" should keep current status, but it actually tries to pop patches because of X. The index in "the series" should be used to examine "pushable" of a patch by "mq.pushablek()", but the index in "applied patches" is used, and this may cause unexpected examination of guarded patch. To examine "pushable" of already applied patch correctly, this patch uses "mq.applied[i].name": "pushable" is the function introduced by the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
Fri, 12 Sep 2014 02:29:19 +0900 mq: pop correct patches when changing pushable-ness of already applied ones stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22455
mq: pop correct patches when changing pushable-ness of already applied ones Before this patch, "hg qselect" with --pop/--reapply may pop incorrect patches, because the index in "applied patches" is used to pop patches by "mq.pop()", even though the index in "the series" should be used. For example, when the already applied patch becomes guarded and it follows the already guarded (= not yet applied) one, "hg qselect" is aborted, because it tries to pop to guarded one. This patch uses "mq.applied[i - 1].name" to pop to the patch, of which the index in the "applied ones" is "i - 1".
Fri, 12 Sep 2014 02:29:19 +0900 mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22454
mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety Before this patch, "hg qselect --reapply" is aborted when "--verbose" is specified, because "mq.appliedname()" returns "INDEX PATCHNAME" instead of "PATCHNAME" in such case and "mq.push" can't accept the former as the name of patch. This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as the name of the patch to be pushed for safety. Now, there is no code path using "mq.appliedname()", and it should be removed to prevent developers from using it in the wrong way like this issue.
Fri, 12 Sep 2014 02:29:19 +0900 mq: report correct numbers for changing "number of guarded, applied patches" stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 12 Sep 2014 02:29:19 +0900] rev 22453
mq: report correct numbers for changing "number of guarded, applied patches" Before this patch, "hg qselect" may report incorrect numbers for "number of guarded, applied patches has changed", because it examines "pushable" of patches by the index not in "the series" but in "applied patches", even though "mq.pushable()" expects the former. To report correct numbers for changing "number of guarded, applied patches", this patch uses the name of applied patch to examine pushable-ness of it. This patch also changes the result of existing "hg qselect" tests, because they doesn't change pushable-ness of already applied patches. This patch assumes that "hg qselect" focuses on changing pushable-ness only of already applied patches, because: - the report message uses not "previous" (in the series) but "applied" - the logic to pop patches for --pop/--reapply examines pushable-ness only of already applied ones (in fact, there are some incorrect code paths)
Fri, 29 Aug 2014 05:09:59 +0200 annotate: remove redundant check for empty list of annotation data
Yuya Nishihara <yuya@tcha.org> [Fri, 29 Aug 2014 05:09:59 +0200] rev 22452
annotate: remove redundant check for empty list of annotation data It isn't necessary because zip(*pieces) returns [] if pieces are empty, and pieces are empty only if lines are empty.
Fri, 12 Sep 2014 14:21:18 -0700 revset: lower weight for _intlist function
Durham Goode <durham@fb.com> [Fri, 12 Sep 2014 14:21:18 -0700] rev 22451
revset: lower weight for _intlist function The histedit command uses a revset like: (_intlist('1234\x001235')) and merge() Previously the optimizer gave a weight of 1.5 to the _intlist side (1 for the function, 0.5 for the string) which caused it to process the merge() side first. This caused it to evaluate merge against every commit in the repo, which took 2.5 seconds on a large repo. I changed the weight of _intlist to 0, since it's a trivial calculation, which makes it process intlist first, which makes merge apply only to the revs in the list. Which makes the revset take 0.15 seconds now. Cutting off 2.4 seconds off our histedit performance. >From the revset benchmark: revset #25: (_intlist('20000\x0020001')) and merge() 0) obsolete feature not enabled but 54243 markers found! ! wall 0.036767 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) 1) obsolete feature not enabled but 54243 markers found! ! wall 0.000198 comb 0.000000 user 0.000000 sys 0.000000 (best of 9084)
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip