Reputation: 11327
Running git log --first-parent -p
shows me the commits I am interested in but I want to see the patch for the merge commits as well as non-merge commits (-p
only shows the patch for non-merge commits).
Is there a way to see the patch for merge commits?
Upvotes: 5
Views: 1798
Reputation: 489818
There are a bunch of options to control this.
The basic problem with diff-ing a merge commit is that there are multiple parents (by definition, since it's a merge). What git show
(which, I know, is not git log
, hang on a moment) does by default is show you a "combined diff", which is properly described in yet another different documentation page, for git diff-tree
:
-c
This flag changes the way a merge commit is displayed (which means it is useful only when the command is given one tree-ish, or
--stdin
). It shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent and the result one at a time (which is what the-m
option does). Furthermore, it lists only files which were modified from all parents.--cc
This flag changes the way a merge commit patch is displayed, in a similar way to the
-c
option. It implies the-c
and-p
options and further compresses the patch output by omitting uninteresting hunks whose the contents in the parents have only two variants and the merge result picks one of them without modification. When all hunks are uninteresting, the commit itself and the commit log message is not shown, just like in any other “empty diff” case.
We're now ready to hop all the way out to git log
, which implements all three options (-c
, --cc
, and -m
; note that --cc
uses two -
characters while the others use just one). Adding one of these will produce a patch for a merge commit. Specifically, you probably want -m
. This is actually described in the documentation (near the end of the web page):
git log -p -m --first-parent
Shows the history including change diffs, but only from the “main branch” perspective, skipping commits that come from merged branches, and showing full diffs of changes introduced by the merges. This makes sense only when following a strict policy of merging all topic branches when staying on a single integration branch.
Upvotes: 8