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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Feb 24, 2023, 19:24 UTC
Message-ID: <2b28155d-f82d-06b8-2df9-135608c6bf63@dunelm.org.uk>
In-Reply-To: <xmqqpm9yzxky.fsf@gitster.g>

On 24/02/2023 19:13, Junio C Hamano wrote:

Show 8 quoted lines

> Alex Henrie <alexhenrie24@gmail.com> writes:
> 
>> Phillip is concerned about people and scripts assuming that
>> --rebase-merges is equivalent to --rebase-merges=no-rebase-cousins,
>> see [1].
> 
> Isn't that already broken when you introduce rebase.merges
> configuration?

Scripts using --rebase-merges are not broken by the introduction of rebase.merges so long as we follow our usual convention of always allowing the commandline to override the config (i.e. --rebase-merges is always equivalent to --rebase-merges=no-rebase-cousins). I don't really understand why Alex is suggesting splitting the config into two based on my comments.

> People and scripts are already relying on the lack
> of rebase-merges to flatten, and script writers will be surprised to
> receive a "bug report" complaining that their script does not work
> when the users set rebase.merges to anything but no.

That is true.

Best Wishes

Phillip

Show 13 quoted lines

>> Tao and others are probably not going to like it if --rebase-merges
>> without an argument undoes a rebase.merges=rebase-cousins
>> configuration.
> 
> That is why I suggested to keep --rebase-merges= (with no value or
> an empty string) only for those who came from the world where it
> defaults to no-rebase-cousins and there was no rebase.merges
> configuration.  If --rebase-merges= is given from the command line
> without value *and* rebase.merges configuration is there (which is
> Tao's concern?), the command line option can error out asking for an
> explicit value to countermand whatever value is configured.
> 
> Wouldn't that work for folks from both camps?