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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 24, 2023, 18:08 UTC
Message-ID: <xmqqcz5z0wdb.fsf@gitster.g>
In-Reply-To: <CAMMLpeQKJeZn4rcTJzFR-ixQXKQMT7t-BKvJqXV4o_4VM=tHYg@mail.gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

Show 5 quoted lines

> 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.