rebase: skip obsolete commits even if they have pruned successors Issue 5782 reported that `hg rebase -r <obsolete commit with pruned successor>` failed with an error saying that it would cause divergence. Commit b7e2cf114e85 (rebase: do not consider extincts for divergence detection (issue5782), 2018-02-09) fixed it by letting you rebase the commit. However, that fix seems inconsistent with how we handle `hg rebase -r <pruned commit>`. To me, it should make no difference whether a commit is pruned itself or if it has (only) pruned successors. This patch changes it so we treat these two kinds of commits the same way. I let the message we print remain "note: not rebasing <commit>, it has no successor" even though that last part is not technically correct for commits with pruned successors. I doubt it will confuse users. Differential Revision: https://phab.mercurial-scm.org/D10240

tests: ask any chg instance to terminate before looking at sqlite dbs There are spurious errors in CI where the database is still locked, so force the daemon to quit to get deterministic behavior. Since the kill command itself is racy, also sleep 2s to give the server time to wake up and exit. Differential Revision: https://phab.mercurial-scm.org/D10244

chg: kill trailing comma in SEE ALSO Differential Revision: https://phab.mercurial-scm.org/D10243

bisect: use standard one-line commit summary This makes bisect use the standardized support for one-line commit summary I added a while back. That means that it will respect the `command-templates.oneline-summary` config. If also means that the default output now includes the first line of the commit message (see test impact). Differential Revision: https://phab.mercurial-scm.org/D10245