On 24/02/2023 19:13, Junio C Hamano 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?
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?
