On Fri, Feb 24, 2023 at 12:13 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> 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? 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. Yeah, I don't know why breaking the assumption that --rebase-merges is equivalent to --rebase-merges=no-rebase-cousins is any worse than breaking the assumption that not passing --rebase-merges is equivalent to passing --no-rebase-merges. And the assumption is broken whether one new config option is introduced or two, so splitting the option up probably wouldn't make Phillip any happier. > > 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? Maybe. I still don't like the idea of --rebase-merges="" ever being not equivalent to rebase.merges="". -Alex
