diff tests/test-rebase-obsolete.t @ 33332:3b7cb3d17137

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.

--- a/tests/test-rebase-obsolete.t	Mon Jun 26 13:13:51 2017 -0700
+++ b/tests/test-rebase-obsolete.t	Fri Jul 07 18:51:46 2017 -0700
@@ -974,9 +974,12 @@
   $ hg log -r .
   3:be1832deae9a b (no-eol)
 
-Check that bookmark was moved to rev 3 although rev 2 was skipped
-during the rebase operation
+Check that bookmark was not moved to rev 3 if rev 2 was skipped during the
+rebase operation. This makes sense because if rev 2 has a successor, the
+operation generating that successor (ex. rebase) should be responsible for
+moving bookmarks. If the bookmark is on a precursor, like rev 2, that means the
+user manually moved it back. In that case we should not move it again.
   $ hg bookmarks
-     mybook                    3:be1832deae9a
+     mybook                    2:1e9a3c00cbe9
   $ hg debugobsolete --rev tip
   1e9a3c00cbe90d236ac05ef61efcc5e40b7412bc be1832deae9ac531caa7438b8dcf6055a122cd8e 0 (*) {'user': 'test'} (glob)