On 15/01/2020 19:14, Junio C Hamano wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > > 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. FYI (and anyone interested), it`s something we actually brought up some two years ago, at the time of introducing `--rebase-merges` (known as `--recreate-merges` back at the time), see[1]. It ended being a lengthy and heated discussion (inside a few different topics as well, like original RFC[2] and it`s v2 update[3]), myself being guilty for dropping out eventually and not following it through, though, life taking me in another direction at the moment... but I still find this functionality to be very useful, not to say essential, even, for reliable complex merge _rebasing_ (meaning keeping "evil merge" changes, too), and not just merge _recreating_ (loosing "evil merge" changes, and worse - doing it silently, as you experienced yourself now as well). p.s. Bringing that one up again, it can`t go without saying a huge thanks to Dscho for taking it this far in the meantime anyway <3 Regards, Buga [1]: https://lore.kernel.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@xxxxxxxxx/ [2]: https://lore.kernel.org/git/87y3jtqdyg.fsf@xxxxxxxxx/ [3]: https://lore.kernel.org/git/87r2oxe3o1.fsf@xxxxxxxxx/
