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.
Details
Details
- Reviewers
- None
- Group Reviewers
hg-reviewers - Commits
- rHG32399d0813e0: rebase: skip obsolete commits even if they have pruned successors
Diff Detail
Diff Detail
- Repository
- rHG Mercurial
- Branch
- default
- Lint
No Linters Available - Unit
No Unit Test Coverage