Re: [PATCH v5 00/12] rebase -i: offer to recreate merge commits

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 7, 2018, 13:50 UTC
Message-ID: <nycvar.QRO.7.76.6.1803071445510.20700@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <bc9f82fb-fd18-ee45-36a4-921a1381b32e@gmail.com>

Hi Buga,

On Tue, 6 Mar 2018, Igor Djordjevic wrote:

Show 6 quoted lines

> [...]
>
> 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).

Show 5 quoted lines

> 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