[Bug 5039] New: Histedit defaultrev should not stop at changesets with obsolete children

[mercurial-bugs at selenic.com]

https://bz.mercurial-scm.org/show_bug.cgi?id=5039

            Bug ID: 5039
           Summary: Histedit defaultrev should not stop at changesets with
                    obsolete children
           Product: Mercurial
           Version: default branch
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: histedit
          Assignee: bugzilla at selenic.com
          Reporter: gregory.szorc at gmail.com
                CC: mercurial-devel at selenic.com

By default, `hg histedit` will select the base revision using the revset
"reverse(only(.) and not public() and not ::merge())".

I have repo history that looks like the following:

@   6044:8dda54288a34 gps tip
|  reviewboard: convert pushreview command to JSON (bug 1234413); r?smacleod
o   6038:9bd46b64387a gps
|  reviewboard: refactor warning recording into protocol command; r?smacleod
o   6037:7a520505dcef gps
|  testing: remove bad imports test; r?smacleod
o   6036:3ee33fa4d18d gps
|  reviewboard: convert pullreviews command to JSON (bug 1234413); r=smacleod
o   6035:68e2f51bc28a gps
|  reviewboard: convert publishreviewrequests command to JSON (bug 1234413);
r=smacleod
| o   6033:09641024f7b2 gps
| |  INCOMPLETE: reviewboard: port review submission logic to web command
| o   6032:eb48f735d6ec gps
| |  git-push-mozreview: git command for pushing to mozreview (bug 1153053)
| x   6031:8717bbdefe14 gps
|/   reviewboard: convert pushreview command to JSON (bug 1234413); r?smacleod
o   6026:85ce50d5fd5f gps
|  reviewboard: convert reviewrepos command to JSON (bug 1234413); r=smacleod
o   6025:99b2639243f4 gps
|  reviewboard: declare jsonproto capability (bug 1234413); r=smacleod
o   6024:50970fdd1690 gps
|  reverboard: use demandimport.deactivated; r?smacleod

`hg histedit` picks 6035:68e2f51bc28a as the base revision because its parent
has multiple children. We purposefully implemented histedit to stop at
changesets with multiple children because having to deal with merge conflicts
while rebasing the other DAG heads would make the UX a bit complex. However, in
the case of those children already being obsolete, I don't believe the rebase
will occur automatically, so we don't have to worry about the UX issues.

I think histedit should bypass changesets with only obsolete children when
choosing the base revision.

-- 
You are receiving this mail because:
You are on the CC list for the bug.