Re: [PATCH 3/5] diff-merges: implement log.diffMergesForce config

From: Elijah Newren <newren@gmail.com>
Date: Nov 29, 2022, 05:10 UTC
Message-ID: <CABPp-BFHQ8KwNK=FKGc96iQYqr9xT--WH7kg5R-CzCaAiWiRZg@mail.gmail.com>
In-Reply-To: <20221127093721.31012-4-sorganov@gmail.com>

On Sun, Nov 27, 2022 at 1:37 AM Sergey Organov <sorganov@gmail.com> wrote:

Show 36 quoted lines

>
> Force specified log format for -c, --cc, and --remerge-diff options
> instead of their respective formats. The override is useful when some
> external tool hard-codes diff for merges format option.
>
> Using any of the above options twice or more will get back the
> original meaning of the option no matter what configuration says.
>
> Signed-off-by: Sergey Organov <sorganov@gmail.com>
> ---
>  Documentation/config/log.txt | 11 +++++++++++
>  builtin/log.c                |  2 ++
>  diff-merges.c                | 32 ++++++++++++++++++++++++++------
>  diff-merges.h                |  2 ++
>  t/t4013-diff-various.sh      | 18 ++++++++++++++++++
>  t/t9902-completion.sh        |  3 +++
>  6 files changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/config/log.txt b/Documentation/config/log.txt
> index 265a57312e58..7452c7fad638 100644
> --- a/Documentation/config/log.txt
> +++ b/Documentation/config/log.txt
> @@ -43,6 +43,17 @@ log.diffMergesHide::
>  log.diffMerges-m-imply-p::
>         `true` enables implication of `-p` by `-m`.
>
> +log.diffMergesForce::
> +       Use specified log format for -c, --cc, and --remerge-diff
> +       options instead of their respective formats when the option
> +       appears on the command line one time. See `--diff-merges` in
> +       linkgit:git-log[1] for allowed values. Using 'off' or 'none'
> +       disables the override (default).
> ++
> +The override is useful when external tool hard-codes one of the above
> +options. Using any of these options two (or more) times will get back
> +the original meaning of the options.

I didn't quite understand your intent here from this explanation. When you pointed out to Junio that you wanted to override magit's hard-coded `git log --cc` and turn it into `git log -m -p`, then it suddenly made more sense. And the two or more times I guess is your escape hatch to allow users to say "I *really* do want this other format, so `git log --cc --cc` will get it for me.".

Maybe something like:

Override -c, --cc, --remerge-diff options and use the specified diff-generation scheme for merges instead. However, this config setting can in turn be overridden by specifying an alternate option multiple times (e.g. `git log --cc --cc`). Overriding the diff-generation scheme for merges can be useful when an external tool has a hard-coded command line it calls such as `git log --cc`. See `--diff-merges` in linkgit:git-log[1] for allowed values. Using 'off' or 'none' disables the override (default).

However:
  * This feels like we're trying to workaround bugs or inflexibility
in other tools with code in Git.  This feels like a slippery slope
issue and/or fixing the wrong tool.
  * Why is this just for -c, --cc, and --remerge-diff, and not for
also overriding -m?  It seems odd that one would be left out,
especially since tools are more likely to have hard-coded it than
--remerge-diff, given that -m has been around for a long time and
--remerge-diff is new.

> +
>  log.follow::
>         If `true`, `git log` will act as if the `--follow` option was used when
>         a single <path> is given.  This has the same limitations as `--follow`,

[...]

Show 12 quoted lines

> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 1789dd6063c5..8a90d2dac360 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -557,6 +557,24 @@ test_expect_success 'git config log.diffMerges-m-imply-p has proper effect' '
>         test_cmp expected actual
>  '
>
> +test_expect_success 'git config log.diffMergesForce has proper effect' '
> +       git log -m -p master >result &&
> +       process_diffs result >expected &&
> +       test_config log.diffMergesForce on &&

I think the default for `on` is bad; it made sense at the time, but I think we have a better option now. Perhaps we switch to it, perhaps we don't, but if there's _any_ chance at all we change the default for "on" (which I think there definitely is), then you should really use the option that matches the actual mode you are using rather than a synonym for it; doing so future-proofs this testcase.

Show 9 quoted lines

> +       git log --cc master >result &&
> +       process_diffs result >actual &&
> +       test_cmp expected actual
> +'
> +
> +test_expect_success 'git config log.diffMergesForce override by duplicate' '
> +       git log --cc master >result &&
> +       process_diffs result >expected &&
> +       test_config log.diffMergesForce on &&

Matters less here, but just in case "--cc" were to become the default, it'd be nice to explicitly use something else like separate here.

> +       git log --cc --cc master >result &&
> +       process_diffs result >actual &&
> +       test_cmp expected actual
> +'