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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux