git log --merge: Viewing Commits That Caused a Conflict

When you're in the middle of a paused, conflicted merge, it's often not enough to just see the conflicting content — you want to know *why* each side changed that section, and in which specific commits. `git log --merge` is designed exactly for this moment, filtering history down to only the commits on both branches that actually touched the conflicting file since their common ancestor.

Learning Objectives

Use git log --merge during a paused conflict to see relevant commits from both sides.
Combine git log --merge with -p to see the actual diffs of those relevant commits.
Understand how this differs from a normal git log, which would show far more unrelated history.
Use this information to make better-informed conflict resolution decisions.

Key Terms to Know Before Learning git log --merge

git log --merge: A specialized git log invocation, usable only during an unresolved merge, that shows commits on both branches which touched files currently in conflict.
MERGE_HEAD: A temporary reference Git creates during a paused merge, pointing to the tip of the branch being merged in — used internally by commands like git log --merge.
Relevant commit: In this context, a commit that modified a file currently involved in a conflict, as opposed to any other unrelated commit in the branch's history.

How git log --merge Actually Works

During a normal, resolved repository state, `git log --merge` doesn't do anything special — it's specifically meaningful only while a merge is currently paused due to conflicts. At that moment, Git has two relevant reference points: your current `HEAD`, and a temporary reference called `MERGE_HEAD`, which points to the tip of the branch you're in the process of merging in.

Running:

```
git log --merge
```

filters history down to only the commits, from both `HEAD`'s side and `MERGE_HEAD`'s side, that touched any file currently listed as conflicted — since their most recent common ancestor. This is dramatically more focused than a plain `git log`, which would show the entire history of both branches, most of which is completely irrelevant to understanding the specific conflict at hand.

For even more insight, combine this with `-p` (patch), which additionally shows the full diff of each of those relevant commits:

```
git log --merge -p
```

This lets you see not just *which* commits touched the conflicting area, but *exactly what* each one changed — often revealing the actual reasoning or intent behind each side's edit (especially if commit messages were written clearly, per Module 1's guidance on atomic, well-messaged commits), which can make the correct resolution far more obvious than just staring at the raw conflict markers alone.

A practical workflow: when you hit a conflict and the correct resolution isn't immediately obvious just from looking at the markers, run `git log --merge -- <conflicted-file>` (optionally scoped to just that file) to pull up the specific commits responsible on both sides. Reading their commit messages and diffs often clarifies *why* each change was made — perhaps one was a genuine bug fix that must be preserved, while the other was an unrelated formatting change that can be safely overridden — turning an ambiguous decision into an informed one.

This command is a good example of Git providing specialized tooling for a very specific, narrow moment (an active, unresolved conflict) rather than expecting you to piece together the same information manually from a much broader, general-purpose `git log` of the entire project.

git log --merge: Visual Walkthrough

Draw two branch lines converging toward a conflict point. On the HEAD (main) side, show three commits, only one of which (highlighted) touched the conflicted file. On the MERGE_HEAD (feature) side, show four commits, only two of which (highlighted) touched the conflicted file. Draw a funnel labeled 'git log --merge' collecting only the highlighted, relevant commits from both sides into a short, focused list — contrasted with a crossed-out 'plain git log (shows ALL 7 commits from both sides, mostly irrelevant)'.

Command vs Shows: Key Differences

Command	Shows
git log --merge	Commits from both HEAD and MERGE_HEAD that touched currently conflicted files
git log --merge -p	Same as above, plus the full diff of each relevant commit
git log --merge -- <file>	Scoped further to relevant commits touching just that specific file
git log (plain, during conflict)	The full history of the current branch only — not specifically focused on the conflict

git log --merge: Command Syntax and Examples

# During a paused, conflicted merge:
git status
# Unmerged paths: both modified: app.js

# See only commits from both sides relevant to the conflicted file
git log --merge

# Include full diffs for deeper context
git log --merge -p

# Scope specifically to one conflicted file
git log --merge -p -- app.js

Breaking Down the git log --merge Example

After confirming `app.js` is conflicted via `git status`, `git log --merge` narrows the otherwise overwhelming full history down to just the specific commits, from both your current branch and the branch being merged in, that actually modified `app.js` since their common ancestor. Adding `-p` reveals the exact diffs of those commits, often making the reasoning behind each conflicting change immediately clear — for example, showing that one side's change was a critical bug fix, informing a much more confident resolution decision than working from the bare conflict markers alone.

How git log --merge Is Used on Real Engineering Teams

Engineers resolving conflicts in unfamiliar or legacy sections of a codebase frequently reach for git log --merge -p specifically to understand the historical intent behind each conflicting change before deciding how to resolve it.
Code review culture at some companies encourages referencing the relevant commit messages found via git log --merge directly in the eventual merge commit's message, documenting exactly how and why a conflict was resolved.
This command is particularly valuable in large, long-lived feature branches where dozens of commits may exist on each side, making a manual, unaided review of full history impractical.
Senior engineers often teach this command specifically to junior developers who otherwise resolve conflicts by guesswork alone, without understanding the historical context behind each competing change.

git log --merge Interview Questions and Answers

Q1. What does git log --merge show, and when is it useful?

It's meaningful only during a currently paused, conflicted merge, and shows the commits from both your current branch (HEAD) and the branch being merged in (MERGE_HEAD) that touched any file currently involved in a conflict, since their common ancestor. It's useful for understanding the historical context and intent behind each side's conflicting change before deciding how to resolve it.

Q2. How does git log --merge differ from a plain git log during a conflict?

A plain git log would show the entire history of the current branch, most of which is unrelated to the specific conflict at hand. git log --merge specifically filters this down to only the relevant commits from both sides that actually touched the conflicting content, making it far more focused and useful in that moment.

Q3. How would you get more detail than just the list of relevant commits from git log --merge?

Add the -p (patch) flag, as in git log --merge -p, which additionally shows the full diff of each relevant commit, revealing exactly what changed and often clarifying the intent behind each side's edit.

git log --merge Quiz: Test Your Understanding

1. When is git log --merge specifically meaningful to run?

At any point in a repository's history
Only during a currently paused, unresolved merge conflict
Only immediately after cloning a repository
Only when using git rebase instead of git merge

Answer: B. Only during a currently paused, unresolved merge conflict

Explanation: git log --merge relies on the temporary MERGE_HEAD reference that only exists while a merge is actively paused due to conflicts, making it meaningful specifically in that context.

2. What does git log --merge filter its output to show?

Every commit ever made in the repository
Only commits from both branches that touched files currently listed as conflicted
Only the very first commit shared by both branches
Only commits made in the last 24 hours

Answer: B. Only commits from both branches that touched files currently listed as conflicted

Explanation: It narrows history specifically to relevant commits — those from HEAD and MERGE_HEAD that modified currently conflicted content since their common ancestor — rather than showing all history.

3. What does adding -p to git log --merge provide?

A list of all branches in the repository
The full diff content of each relevant commit found
A count of how many conflicts exist
A way to automatically resolve the conflict

Answer: B. The full diff content of each relevant commit found

Explanation: The -p (patch) flag adds the actual line-by-line diff for each commit in the filtered list, providing deeper insight into exactly what each relevant commit changed.

git log --merge: Common Mistakes Beginners Make

Trying to run git log --merge outside of an actual paused conflict and being confused when it behaves unexpectedly or shows nothing particularly special.
Resolving conflicts purely by guesswork from the raw markers, without checking git log --merge -p for helpful historical context first.
Not scoping the command to a specific file (using -- <file>) in a large merge with many conflicted files, resulting in a still-overwhelming amount of output.
Assuming this command performs any resolution itself — it is purely investigative, providing information, not modifying anything.

git log --merge: Exam-Ready Quick Notes

git log --merge: meaningful only during a paused, conflicted merge; shows relevant commits from both HEAD and MERGE_HEAD.
Filters specifically to commits that touched currently conflicted files, unlike plain git log which shows all history.
Add -p for full diffs of those relevant commits; scope with -- <file> for a single conflicted file.
Purely investigative — provides context to inform resolution decisions, does not resolve anything itself.

git log --merge: Key Takeaways

git log --merge cuts through the noise of full project history, showing only commits genuinely relevant to a current conflict.
Combining it with -p often reveals the actual reasoning behind each competing change, turning guesswork into an informed resolution decision.
This is a purely investigative, read-only command — it complements, but doesn't replace, the actual resolution steps covered in earlier lessons.

Frequently Asked Questions About git log --merge

Q1. What does git log --merge do?

During an active, unresolved merge conflict, it shows only the commits from both branches involved in the merge that touched the currently conflicted file(s), rather than the entire history of both branches.

Q2. When can I actually use git log --merge?

Specifically while a merge is currently paused due to unresolved conflicts. It relies on a temporary reference (MERGE_HEAD) that only exists in that situation, so it's not meaningful to run at other times.

Q3. How is this different from just running git log normally during a conflict?

A plain git log would show the full history of your current branch, most of which has nothing to do with the specific conflict. git log --merge filters this down specifically to commits from both sides that actually touched the conflicting content.

Q4. How can I see the actual code changes from the commits git log --merge finds?

Add the -p flag: git log --merge -p. This shows the full diff for each relevant commit, which often makes the reasoning behind a conflicting change much clearer than just looking at the raw conflict markers.

Q5. Does git log --merge help resolve the conflict automatically?

No, it's a purely investigative, read-only command. It gives you helpful context and history to inform your decision, but you still need to manually (or with a tool) edit, stage, and commit the actual resolution.

Summary

`git log --merge`, meaningful specifically during a currently paused, unresolved merge conflict, filters commit history down to only the commits from both your current branch (`HEAD`) and the branch being merged in (`MERGE_HEAD`) that touched any file currently involved in a conflict, since their common ancestor. This is far more focused than a plain `git log`, which would show the entire, largely irrelevant history of both branches. Adding `-p` reveals the full diff of each relevant commit, often clarifying the actual reasoning behind each side's conflicting change and turning an ambiguous resolution decision into a well-informed one. It's a purely investigative, read-only command that complements — but doesn't replace — the actual resolution steps of editing, staging, and committing.