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

From: Glen Choo <chooglen@google.com>
Date: Mar 16, 2023, 22:46 UTC
Message-ID: <kl6lttykuxfu.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <CAMP44s3hH0Gw71UAm10Os=6YJ4RAoAJxC3exN_jekMy6-JRsVg@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 11 quoted lines

>> --[no-]rebase-merges [--rebase-merges-mode=(rebase-cousins|no-rebase-cousins)]
>>
>> I don't think there would be any confusion.
>> [...]
>> (Having --rebase-merges-mode
>> be a no-op without --rebase-merges is probably even more confusing to
>> users, plus this would break backwards compatibility, so I don't think
>> this is a good idea at all.)
>
> I don't find it confusing. And how would it break backwards
> compatibility if --rebase-merges-mode doesn't exist now?

I meant that for the above example to work, we would need to have `--[no-]rebase-merges` as a boolean that says whether we rebase merges at all, and `--rebase-merges-mode=[whatever]` would tell us what mode to use _if_ we were rebasing merges. This means that `--rebase-merges=not-a-boolean` would become invalid.

We were in this position before, actually, with `git log -p -m`. The conclusion on a recent series [1] is that having such a no-op flag was probably a mistake (and unfortunately, one that is extremely hard to fix due to backwards compatibility requirements), so introducing more no-op flags is probably a bad idea :)

[1] https://lore.kernel.org/git/871qn5pyez.fsf@osv.gnss.ru