On Thu, Mar 16, 2023 at 4:46 PM Glen Choo <chooglen@xxxxxxxxxx> wrote: > > 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. No, we don't need --no-rebase-merges for --rebase-merges-mode to work. It would be nice, but not necessary. > This means that > `--rebase-merges=not-a-boolean` would become invalid. No, it would not become invalid, that's yet another decision to make. `--rebase-merges=mode` could become synonymous with `--rebase-merges --rebase-merges-mode=mode`. A shortcut. Because it's redundant it could be deprecated in the future, but not necessarily 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), No, `git log -m` was a mistake *only* if -p isn't turned on as well, which is an interface wart that could be fixed today. > so introducing more no-op flags is probably a bad idea :) Whether --rebase-merges-mode turns on --rebase-merges by default is a decision that could be made in the future. Just like `git log -m` turning on `-p` by default is a decision that could be made in the future (and probably should). --- Either way: introducing a new option cannot possibly break backwards compatibility. Cheers. -- Felipe Contreras
