[PATCH 1 of 2] strip: add a delayedstrip method that works in a transaction

[Jun Wu]

Excerpts from Martin von Zweigbergk's message of 2017-06-27 13:16:17 -0700:
> I think allowduplicates is quite different from allowunstable. We can
> automate resolution of unstable commits, but we can't automate
> resolution of duplicates. I'm still convinced it's a bug in a the
> command that creates the duplicate commit (unless that's the command's
> purpose, of course, but then it really shouldn't attempt to strip one
> of the commits).

That's why it's "power user" only. I agree that the default behavior could
be abort. But I think it's reasonable to make it possible for power users to
not abort. If you think nobody is such power user, then my question is, why
not remove "--force" from "hg phase" ? since that also helps create
duplicated changesets indirectly.

> I understand that the user can add commits, and I suppose that's
> covered by that test-rebase-interruptions.t. However, I don't see how
> they can trigger the ProgrammingError.

The current code without modification will. I guess you mean moving the
unstable check to "rebase --continue" code path. That is a BC to
test-rebase-interruptions.t that I'd prefer not to break.

At this point, I'd also like a third party to jump in. Since my silly
"allowduplicates" seems bad, and I don't want to break
test-rebase-interruptions.t, I'll leave the code as is. Feel free to send
patches and start a new discussion if you see fit.