Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: >> --[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@xxxxxxxxxxx
