Given the graph: $ hg debugdrawdag <<'EOF' > D H > | | > C G > | | > B F > | | > Z A E > \|/ > R > EOF Run "hg rebase -r B+D+E+G+H -d Z" And the result is: o 7:721b8da0a708 H | o 6:9d65695ec3c2 G | o 5:21c8397a5d68 E | | o 4:fc52970345e8 D | | | o 3:eac96551b107 B |/ o 2:f424eb6a8c01 Z | | o 1:21a6c4502885 A |/ o 0:b41ce7760717 R Changeset C and F are stripped incorrectly. Note: I have fixed this locally and will send patches soon.
Is this with allowunstable in evolution.allowunstable? I assume it's not, because there should be no stripping involved (obsmarkers should be created instead). But without it, I would say that the bug is not that those commits are stripped, but that it doesn't abort before even starting with "can't remove original changesets with unrebased descendants".
I think the rebase should continue. Otherwise it's impossible for users to do that rebase without obsstore turned off. That is similar to a bug of "hg absorb" [1]. In that case, I don't think abort is a good choice and the fix was to not strip the children. My cleanup patch [2] has fixed this issue as a side effect. [1]: https://bitbucket.org/facebook/hg-experimental/issues/6/hg-absorb-merges-diverged-commits [2]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/100245.html
I think you're saying that you think the "can't remove original changesets with unrebased descendants" error should never happen (kind of, but not quite, like automatically adding the --keep instead). That seems like a great patch to send early in the series in that case so it's clear that that's what's happening and we can discuss that decision separately.
I think with "allowunstable" turned on, it should continue. With "allowunstable" turned off, it should abort.
I tried to add a test case for this. The following test passes. My impression from this bug was that it would fail (by not aborting). The abort behavior is exactly what we want, isn't it? diff --git a/tests/test-rebase-detach.t b/tests/test-rebase-detach.t --- a/tests/test-rebase-detach.t +++ b/tests/test-rebase-detach.t @@ -1,6 +1,7 @@ $ cat >> $HGRCPATH <<EOF > [extensions] > rebase= + > drawdag=$TESTDIR/drawdag.py > > [phases] > publish=False @@ -415,3 +416,24 @@ Ensure --continue restores a correct sta $ cd .. + + $ hg init issue5606 + $ cd issue5606 + $ hg debugdrawdag <<'EOF' + > D H + > | | + > C G + > | | + > B F + > | | + > Z A E + > \|/ + > R + > EOF + + $ hg rebase -r B+D+E+G+H -d Z + abort: can't remove original changesets with unrebased descendants + (use --keep to keep original changesets) + [255] + + $ cd ..
This issue is actually tricky to reproduce. It must be: 1. rebase --config experimental.evolution='allowunstable createmarkers' 2. The rebase must be interrupted by a merge conflict 3. rebase --continue --config experimental.evolution=none So it probably does not affect many users and people toggling the evolution config is probably asking for trouble. That said, the patch still fixes it for this corner case.
An easy way to get in this situation is to: 1) no special config in hgrc (evolve off by default) 2) `hg rebase --config experimental.evolution=all` 3) conflict! 4) `hg rebase --continue` # boom
Fixed by 3b7cb3d17.
Fixed by https://mercurial-scm.org/repo/hg/rev/181ca34883e6 Jun Wu <quark@fb.com> test-rebase-conflicts: add a test case about turning obsstore on and off Turning obsstore and allowunstable on, rebase will skip the "can't remove original changesets with unrebased descendants" check. Then rebase could be interrupted (merge conflict), and the user has a chance to turn off obsstore. If rebase continues, the current code may strip irrelevant commits (in the test case added, "C" got stripped unexpectedly). The test case reproduces issue5606. It will be fixed by the "multidest" rebase refactoring being reviewed. The test case itself is relatively separate from the rebase refactoring, therefore sent separately hoping to reduce the number of patches of the main rebase series. (please test the fix)
Fixed by https://mercurial-scm.org/repo/hg/rev/3b7cb3d17137 Jun Wu <quark@fb.com> rebase: use scmutil.cleanupnodes (issue5606) (BC) This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies the code and makes rebase code reusable inside a transaction. This is a BC because the backup file is no longer strip-backup/*-backup.hg, but strip-backup/*-rebase.hg. The latter looks more reasonable since the directory name is "strip-backup" so there is no need to repeat "backup". I think the backup file name change is probably fine as a BC, since we have changed it before (aa4a1672583e) and didn't get complains. The end result of this series will be a much more consistent and unified backup names: command | old backup file suffix | new backup file suffix ------------------------------------------------------------------- amend | amend-backup.hg | amend.hg histedit | backup.hg (could be 2 files) | histedit.hg (single file) rebase | backup.hg | rebase.hg strip | backup.hg | backup.hg (note: backup files are under .hg/strip-backup) It also fixes issue5606 as a side effect because the new "delayedstrip" code path will carefully examine nodes (safestriproots) to make sure orphaned changesets won't get stripped by accident. Some warning messages are changed to the new "warning: orphaned descendants detected, not stripping HASHES", which provides more information about exactly what changesets are left behind. Another minor behavior change is when there is an obsoleted changeset with a successor in the destination branch, bookmarks pointing to that obsoleted changeset will not be moved. I have commented in test-rebase-obsolete.t explaining why that is more desirable. (please test the fix)
Bug was set to TESTING for 11 days, resolving