On Sun, Jul 9, 2017 at 12:54 PM, Jun Wu <qu...@fb.com> wrote: > 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 <martinv...@google.com> >> > wrote: >> > >> > On Sat, Jul 8, 2017 at 4:51 PM, Jun Wu <qu...@fb.com> wrote: >> >> # HG changeset patch >> >> # User Jun Wu <qu...@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
If we wanted to, we could drop support for the case you in the mention there (with the AD and BC strips) and make each call to delayedstrip() result in one backup (with its own name/topic). I think I prefer that anyway, unless we can think of a concrete example where that case actually occurs in practice. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
