[PATCH 6 of 7] histedit: unify strip backup files on success (BC)

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-07-09 15:28:15 -0400:
> 
> > On Jul 9, 2017, at 2:24 PM, Martin von Zweigbergk <martinvonz at google.com> wrote:
> > 
> > On Sat, Jul 8, 2017 at 4:51 PM, Jun Wu <quark at fb.com> wrote:
> >> # HG changeset patch
> >> # User Jun Wu <quark at fb.com>
> >> # Date 1499557831 25200
> >> #      Sat Jul 08 16:50:31 2017 -0700
> >> # Node ID d75e65724d2bbcf17fcaaad705e463e84a3de5d2
> >> # Parent  9a325ae88021e0e02a87ef1ae6baa8a199405140
> >> # Available At https://bitbucket.org/quark-zju/hg-draft 
> >> #              hg pull https://bitbucket.org/quark-zju/hg-draft  -r d75e65724d2b
> >> histedit: unify strip backup files on success (BC)
> >> 
> >> Previously we wrote two different strip backup files on success. This patch
> >> unifies them. It will make scmutil.cleanupnodes migration more smooth.
> > 
> > Makes sense to me. I'm queuing the series, thanks.
> > 
> > Augie, do you remember if there was a reason to keep them separate?
> 
> The only reason was structural in the code: histedit has “intermediate”
> nodes which are an implementation detail, and “old” nodes, which are the
> precursors to the end state. Internally, the lists are separate because
> you always want to reap “intermediate" nodes, but might want to preserve
> “old” and in --keep or --abort cases.
> 
> It might be nice to keep them separate but have one be marked
> “histedit-internal” and “histedit-before” or something.

Good point.

Going through the "delayedstrip" code path, it could be a bit tricky to
separate backup files [1]. I wish we can count on in-memory-merge work so
those intermediate nodes disappear automatically. But that won't happen
soon. Maybe "delayedstrip" API could be changed, I've added this to my
backlog to resolve.

[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-June/100404.html