Re: [PATCH v6 3/3] rebase: add a config option for --rebase-merges
From: Felipe Contreras <hidden>
Date: 2023-03-16 23:48:29
On Thu, Mar 16, 2023 at 4:46 PM Glen Choo [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:quoted
quoted
--[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