Re: [PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 20, 2019, 00:38 UTC
Message-ID: <xmqqbm26xtum.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <8736nj2jcl.fsf@javad.com>

Sergey Organov <sorganov@gmail.com> writes:

> I think that "first-parent is special" is the way to go indeed for
> porcelain, as it does make many thing easier and more convenient[*].

Perhaps.  However ...

Show 5 quoted lines

> [*] One example that immediately comes to mind is "git log -p" for a
> merge commit. I doesn't currently (as of v2.10) show the first-parent
> diff, for whatever reason. "git log -p -m --first-parent" is needed to
> get the answer to most "obvious" question: what (merge) commit did to my
> mainline? "git show" has its own issues.

... this is very much deliberate and will remain so.

A single ball of wax "diff M^ M" for a merge commit is not always what you would want, especially while viewing "git log -p" (without "--first-parent"). The reason why the user does not explicitly say "--first-parent" is because the user wants to even see the details of individual steps of what happened on side branches.

Incidentally, in such an "I am interested in what happened in each individual step" mode, the primary change that a merge by itself does is better shown with "diff --cc M^ M", not "diff -p M^ M". That is why "show" defaults to "--cc".

"git log -p --first-parent" that requires "-m" to show the single ball of wax diff for a merge is a separate matter. When the user explicitly says "log --first-parent", it is a clear indication that the user does not want to see individual steps of how side branches built what each merge brings into the mainline. From that point of view, ever sice I introduced "--first-parent" traversal, I've been wondering what the true downside would be if we turned "-m" on automatically when these two options are used without "-m".

But it has not disturbed me deeply enough to bother looking into it further.