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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> Sergey Organov <sorganov@xxxxxxxxx> 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 ...
>
>> [*] 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").

OK, point taken. Then it's an issue of suppressing (presumably huge)
parts of output for merge commits by default, and is only vaguely
relevant to the "first parent is special" trend that I intended to
discuss. So, let's leave in peace the "git log -p" for now, and let me
try it from different angle.

How about changing "git show -p M" to output "diff -p M^ M" rather than
"diff-tree --cc M" for merge commits? It's really surprising specifying
-p has no visible effect.

Also, is current output of "git log -m", being extremely confusing,
suitable for anything? Maybe consider to change it to output diff with
respect to the first parent only? Though it's then a pity "-m" lacks
argument here, similar to what it has in cherry-pick.

-- Sergey



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux