On Fri, Feb 24, 2023 at 11:08 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > > > As Johannes pointed out, it's going to be confusing if > > rebase.merges="" does not mean rebase.merges=false. It's also going to > > be confusing if rebase.merges="" does not mean --rebase-merges="". The > > only sane option I see is to drop --rebase-merges="", or to add a > > deprecation warning now and drop it later. > > If we were doing anything, then I think the only sensible way > forward is to warn and then drop long after everybody forgets about > it. > > But does it really need to be changed? I am perfectly happy to > declare that those who wants to set rebase.merges to say false > should set it to false (or no or 0), not an empty string. > > Also, "[rebase] merges = " in the configuration files does not have > to mean the same thing as "--rebase-merges=" from the command line. > Can't we just reserve that strange "--rebase-merges=" given from the > command line to those who are already using it, without even > advertising it in the documentation, document and encourage the > longhand "--rebase-merges=no-rebase-cousins" from the command line > and take only the form that corresponds to it in the configuration > file, i.e. "[rebase] merges = no-rebase-cousins". We could even > error out "[rebase] merges = " in the configuration file, as nobody > is using such a configuration variable today. 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. However, if you think that that's better than deprecating --rebase-merges="" with the plan to drop it long after everybody forgets about it, then I'm happy to oblige. Just let me know what is wanted. -Alex
