From: Phillip Wood Date: Fri, 24 Feb 2023 19:24:42 GMT Subject: Re: [PATCH v4 2/3] rebase: stop accepting --rebase-merges="" Message-ID: <2b28155d-f82d-06b8-2df9-135608c6bf63@dunelm.org.uk> In-Reply-To: On 24/02/2023 19:13, Junio C Hamano wrote: > Alex Henrie 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 >> 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?