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)
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip