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.
