On Fri, Feb 24, 2023 at 11:40 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > > > The only way to truly make "[rebase] merges =" invalid is to print an > > error message and die with that configuration. I think that would be > > confusing too, especially since it's now looking like rebase.merges > > needs to be a pure boolean and an independent rebase.cousins boolean > > option is needed as well. > > Oh, I wasn't aware of that direction. > > I do not know why rebase.cousins, which would only be meaningful > when rebase.merges is true, is a better design than rebase.merges > that is an enum of "don't do the merges stuff" plus "do the merges > stuff with cousins", "without cousins" (which may allow us to gain > more different ways to do "merges stuff" later), but that is what > gained consensus on the list, then "[rebase]merges=" would become a > problem. > > But --rebase-merges from the command line is not a pure Boolean > already, so what does "[rebase]merges" that is a pure Boolean aim to > help? Phillip is concerned about people and scripts assuming that --rebase-merges is equivalent to --rebase-merges=no-rebase-cousins, see [1]. Tao and others are probably not going to like it if --rebase-merges without an argument undoes a rebase.merges=rebase-cousins configuration. It seems to me that the only way to make everyone happy is to have separate rebase.merges and rebase.cousins options. You have a point that separating the options could cause problems if --rebase-merges starts accepting more arguments in the future, but if that happens we could deal with it by adding more possible values to rebase.cousins or introducing a third config option. -Alex [1] https://lore.kernel.org/git/CAMMLpeQ98BTCGE2tcVdZ99eU6cLh4Rd_hc8C_PmKvsBkjXUWPw@xxxxxxxxxxxxxx/
