Re: [PATCH v6 3/3] rebase: add a config option for --rebase-merges

From: Sergey Organov <sorganov@gmail.com>
Date: Mar 25, 2023, 16:59 UTC
Message-ID: <87o7og6a2y.fsf@osv.gnss.ru>
In-Reply-To: <CAMMLpeR4x0_u=JGnWQ1xvBeVBXBw7VAgLTWgvHdMFDZLrcy1pA@mail.gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

[...]

> Let me ask a different but related question: If we add a
> rebase-evil-merges mode, do you think that would be orthogonal to the
> rebase-cousins mode?

This is the question that I considered as well. To me they look orthogonal, and I'm afraid we will have hard times extending --rebase-merges gracefully in a backward-compatible manner.

The set:

--rebase-merges=remerge --rebase-merges=rebase --rebase-merges=off

looks natural to me, but "cousins" that affect what is to be rebased (as opposed to how, if at all), will apparently get in the way. Besides, I recently ran into similar problem with --diff-merges (when|how) dichotomy, and there was no elegant solution found, even though a working one has been implemented, and then there were some discussions around.

Also, I'm not quite sure that these "cousins" options make no sense when we in fact flatten history (--no-rebase-merges case). To me it looks like there should have been separate --[no-]rebase-cousins option, provided we do need this choice in the first place, but I definitely might be wrong here as well.

As a side note, it sounds both unfair and confusing to use "rebase-evil-merges" term to describe a mode that will actually rebase (all the) merges, as neither a merge needs to be 'evil' to be the object of rebase operation, nor dedicated mode is necessarily needed to rebase specifically 'evil' merges (whatever they actually are.)

Thanks, -- Sergey Organov