Re: [PATCH v6 3/3] rebase: add a config option for --rebase-merges

[Alex Henrie <alexhenrie24@gmail.com>]

On Tue, Mar 7, 2023 at 11:32 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
> >> +rebase.rebaseMerges::
> >> +    Whether and how to set the `--rebase-merges` option by default. Can
> >> +    be `rebase-cousins`, `no-rebase-cousins`, or a boolean. Setting to
> >> +    true is equivalent to `--rebase-merges` without an argument,
> >
> > This is a bit picky but how can rebase.rebaseMerges=true be equivalent
> > to --rebase-merges without an argument when the behavior of
> > --rebase-merges without an argument depends on the value of
> > rebase.rebaseMerges?
>
> True.  I think the configuration is meant to give (when set to
> something other than Boolean) the default value to the option
> "--rebase-merges" that is given without value, so setting to false
> should be a no-op (a command line option would override it if given,
> and if there is no command line option, --rebase-merges is not used
> by default), setting it to a specific value between cousin choices
> would give --rebase-merges=<value> unless --no-rebase-merges is
> given, but setting it to true here makes the result undefined,
> unless the built-in default between cousin choices is described
> here.
>
> "Setting to true is equivalent to setting to no-rebase-cousins" and
> "Setting to false is a no-op but accepted only for completeness",
> perhaps?

A false in the local configuration overrides a true in the global
configuration, so I wouldn't call "false" a no-op. But it would be
fine to say that "true" is equivalent to no-rebase-cousins (and then
change the documentation for "true" if and when the default changes in
the future).

> >> +`no-rebase-cousins`. If the mode is not specified on the command line or in
> >> +the `rebase.rebaseMerges` config option, it defaults to `no-rebase-cousins`.
>
> This side could describe what setting it to "true" means, but it is
> a separate page so it would be more friendly to readers to cover it
> on both pages.

The longer the documentation is, the less likely people are to read
any of it. I don't really want to repeat the detailed explanation that
is in git-config.txt, but I see that other places in git-rebase.txt
link to git-config.txt, and having a link seems like a good idea. Fair
enough?

-Alex