Hi Buga, 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 explicit. 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 Hehe... Ciao, Dscho
