Thread (1 message) 1 message, 1 author, 2021-04-11

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

From: Sergey Organov <hidden>
Date: 2021-04-11 18:04:38

Junio C Hamano [off-list ref] writes:
Sergey Organov [off-list ref] writes:
quoted
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".
Yep, that's exactly the plan I have in mind.

To tell the truth, I hope there are no scripts that use "git log -m -p",
or "git show -m", but I do want to be on the safe side with it anyway,
and then sometime in the future maybe we will be safe to change
configuration default.
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.
There are 2 reasons to have "default":

1. --diff-merges=default and -m are not exact synonyms: unlike -m,
--diff-merges=default (similar to other --diff-merges options)
immediately enables diff output for merges, without -p, thus, for
example, allowing to output diffs for merge commits only.

The exact synonyms are rather --diff-merges=m and --diff-merges=default,
and then we get to the next reason:

2. We have descriptive long name for every other option, and it'd be an
exception if we'd have none for --diff-merges=m. In fact, it's
--diff-merges=m that could have been removed, but it'd break resemblance
with --cc and -c that both do have their --diff-merges=cc and
--diff-merges=c counterparts.

Overall, having "default" has both functional and consistency merits.
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.
No, what I have in mind is resurrection of -m as more useful option, not
removing it.

Thanks,
-- Sergey Organov
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help