Re: [PATCH v4 2/3] rebase: stop accepting --rebase-merges=""

[Junio C Hamano <gitster@pobox.com>]

Alex Henrie <alexhenrie24@gmail.com> 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.