Re: [PATCH v1 0/5] git log: configurable default format for merge diffs

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 11, 2021, 16:13 UTC
Message-ID: <xmqqsg3whka6.fsf@gitster.g>
In-Reply-To: <20210410171657.20159-1-sorganov@gmail.com>

Sergey Organov <sorganov@gmail.com> writes:

Show 17 quoted lines

> These patches introduce capability to configure the default format of
> output of diffs for merge commits by means of new log.diffMerges
> configuration variable. The default format is then used by -m,
> --diff-merges=m, and new --diff-merges=default options.
>
> In particular,
>
>   git config log.diffMerges first-parent
>
> will change -m option format from "separate" to "first-parent" that
> will in turn cause, say,
>
>   git show -m <merge_commit>
>
> to output diff to the first parent only, instead of appending
> typically large and surprising diff to the second parent at the end of
> the output.

I think that it is a good goal to free a short-and-sweet "-m" from getting tied forever to the current "two-tree diff for each of the parent" (aka "separate"), and a configuration to change what the "-m" option means would be a good approach to do so. It would help the interactive use by human end-users, which is the point of having short-and-sweet options. Existing scripts may depend on the current behaviour, so the configuration cannot be introduced right away, but over time they can be migrated to use the longer and more explicit option "--diff-merges=separate".

But I do not see much point in adding the "--diff-merges=default". Who is the target audience? Certainly not scripts that want to avoid depending on the 'default' that can be different and easily vary per user.

Or is the plan to deprecate and remove the short-and-sweet "-m" option and standardize on "--diff-merges=<style>"? If so, such a design makes sense from pureness and completeness standpoint, but I am not sure if that is a good design for practical use.