Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Date: Mar 8, 2018, 15:56 UTC
Message-ID: <f3872fb9-01bc-b2f1-aee9-cfc0e4db77d6@gmail.com>
In-Reply-To: <c5a5c2cc-6a11-440f-5b9b-964ae1ca07dd@talktalk.net>

Hi Phillip and Johannes,

On 08/03/2018 12:20, Phillip Wood wrote:

Show 10 quoted lines

> 
> I did wonder about using 'pick <original-merge>' for rebasing merges and
> keeping 'merge ...' for recreating them but I'm not sure if that is a
> good idea. It has the advantage that the user cannot specify the wrong
> parents for the merge to be rebased as 'git rebase' would work out if
> the parents have been rebased, but maybe it's a bit magical to use pick
> for merge commits. Also there isn't such a simple way for the user to go
> from 'rabase this merge' to 'recreate this merge' as they'd have to
> write the whole merge line themselves (though I guess something like
> emacs' git-rebase.el would be able to help with that)

Hmm, funny enough, `pick <original merge>` was something I though about originally, too, feeling that it might make more sense in terms on what`s really going on, but I guess I wanted it incorporated into `--recreate-merges` too much that I tried really hard to fit it in, without changing it much :/

And now that I said this in a previous reply:

Show 8 quoted lines

> The thing is, in my opinion, as long as we are _rebasing_, you can`t 
> pick any merge strategy, as it doesn`t really make much sense. If you 
> do want a specific strategy, than that`s _recreating_ a merge, and it 
> goes fine with what you already have for `--recreate-merges`.
> 
> On merge rebasing, the underline strategy we decide to use is just an 
> implementation detail, picking the one that works best (or the only 
> one that works, even), user should have nothing to do with it.

The difference between "rebase merge commit" and "recreate merge commit" might starting to be more evident.

So... I might actually go for this one now. And (trying to stick with explicit mappings, still :P), now that we`re not married to `merge` expectations a user may already have, maybe a format like this:

  pick <original-merge> <original-parent1>:HEAD <original-parent2>:<new-parent2>

Here, original-merge is a _commit_, where original-parent and new-parent are _labels_ (in terms of `--recreate-merges`).

Everything else I previously said still holds - one is allowed to change or drop mappings, and add or drop new merge parents. Yes, in case user does something "stupid", he`ll get a lot of conflicts, but hey, we shouldn`t judge.

p.s. Are we moving towards `--rebase-merges` I mentioned in that other topic[1], as an add-on series after `--recreate-merges` hits the mainstream (as-is)...? :P

Regards, Buga

[1] https://public-inbox.org/git/bc9f82fb-fd18-ee45-36a4-921a1381b32e@gmail.com/