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

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

 



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.

> 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