I have a number of branches, which are periodically merged, i.e. we can have A, which is merged into B, then B into C, then A into D and D into C, etc. Suppose I have a comm
Usually I do something like the following:
git log --oneline --ancestry-path --merges <commit-of-interest>..C
The --ancestry-path
argument is the key here: it causes git to only show commits that are both a descendant of <commit-of-interest>
AND an ancestor of C
. The --merges
option filters the resulting list further to only show merge commits.
Each of the printed merges falls into one of the following categories:
<commit-of-interest>
into a branch<commit-of-interest>
<commit-of-interest>
The first category is the one you're interested in. You can usually tell which category the merge is in by looking at the commit subject line. Start at the bottom of the list; the oldest merges are the most likely to be in the first category.
It's technically possible to write a script to filter out merges in the second and third categories (just test to see if <commit-of-interest>
is reachable by the merge's first parent), but I've never found it to be necessary.
If you need to do a more in-depth study of the commit history then I recommend looking at the history graph:
git log --oneline --graph --color --decorate \
--ancestry-path <commit-of-interest>..C
You may want to toss in --boundary
too, although sometimes that adds too much noise. You could use gitk
, but unfortunately the graph it draws doesn't show parentage in the correct order (gitk
might draw the edge between a merge and its second parent on the left; git log --graph
always draws the second parent edge on the right).