revset.bisect: add new 'untested' set to the bisect keyword The 'untested' set is made of changesets that are in the bisection range but for which the status is still unknown, and that can later be used to further decide on the bisection outcome. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

revset.bisect: add new 'pruned' set to the bisect keyword The 'pruned' set is made of changesets that did participate to the bisection. They are made of - all good changesets - all bad changsets - all skipped changesets, provided they are in the bisection range Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

revset.bisect: add new 'range' set to the bisect keyword The 'range' set is made of all changesets that make the bisection range, that is - csets that are ancestors of bad csets and descendants of good csets or - csets that are ancestors of good csets and descendants of bad csets That is, roughly equivalent of: bisect(good)::bisect(bad) | bisect(bad)::bisect(good) Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

revset.bisect: move bisect() code to hbisect.py Computing the ranges of csets in the bisection belongs to the hbisect code. This allows for reusing the status computation from many places, not only the revset code, but also to later display the bisection status of a cset... Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

revset: rename bisected() to bisect() Rename the 'bisected' keyword to simply 'bisect'. Still accept the old name, but no longer advertise it. As discussed with Matt on IRC. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

revset.bisected: remove 'unknown' state 'unknown' is not a valid bisect state, so causes a traceback. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>

rebase: allow rebase to ancestor (issue3010) We only deny rebasing onto direct parent. Thanks to the ancestor argument of merge. the "implementation" of this feature only consist in loosing the check and imply detach when rebasing on ancestor.

rollback: only restore dirstate and branch when appropriate. If the working dir parent was destroyed by rollback, then the old behaviour is perfectly reasonable: restore dirstate, branch, and bookmarks. That way the working dir moves back to an existing changeset rather than becoming an orphan. But if the working dir parent was unaffected -- say, you updated to an older changeset and then did rollback -- then it's silly to restore dirstate and branch. So don't do that. Leave the status of the working dir alone. (But always restore bookmarks, because that file refers to changeset IDs that may have been destroyed.)