Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> ... after about 1700+ steps (which did not take more than 20 >> minutes, including the time spent for the manual rebasing of >> en/rebase-backend topic) I got the same tree for 'pu' I pushed out >> last night. > > Nice! Nice indeed---I forgot to say more-or-less there, though ;-) It is quite an achievement to make it practical to rebuild the maint..pu chain, which would involve 1000+ commits, while allowing to edit only a fraction of them. [ellided] observation that tips of the branches that were rewritten in order to rebase the named tip that contains them were left stale > This has been discussed on the list before this past September, but I > think the discussion has stalled after v2 was sent,... That's OK. One step at a time ;-) > Having said that, if you ever find yourself wanting Just One Feature in > `--rebase-merges` that would make it worthwhile for you to think about > switching your patch-based workflow to a `rebase -ir`-based one, please > let me know, and I will try my best to accommodate. Another thing I noticed was that we may want to attempt to recreate an evil merge and then stop to ask confirmation. The "rebase -ri" I did to sanity-check my revert for example failed to bring in the change made in the existing evil merge when trying to recreate the merge of the dl/merge-autostash topic into master..pu chain and silently created a fails-to-build-from-the-source tree instead.
