On Tue, 6 Mar 2018, Igor Djordjevic wrote:
> But before elaborating, I would like to hear your opinion on whether you
> find it worth to pursue that goal here, before `--recreate-merges` hits
> the mainstream, or it might be just fine as a possible later
> improvement, too (if accepted, that is).
As I suggested in another sub-thread, I think the best way forward is to
use your idea to make the 'rebase original merge commits' strategy
That would not actually hold up the current --recreate-merges patch
series, but would mean to provide an add-on patch series to add support
for `merge -R` and then use that from the generated todo list.
For implementation detail reasons, it may actually make sense to integrate
those patches into the --recreate-merges patch series, though. Should not
be hard (except during GitMerge).
> p.s. lol, now that I said it, and after writing all this, I might
> actually even like the idea of (later) having `--rebase-merges`
> alongside `--recreate-merges`, too, each one clearly communicating
> its default mode of operation - rebase merges vs. recreate merges...
> as one might rightfully expect ;) Eh :P