Introduction

When you only want to know which files changed between two revisions, the best command is usually a name-only diff rather than a full content diff. Most version-control tools support this directly. In Git, the standard answer is git diff --name-only rev1 rev2. Other systems such as Subversion and Mercurial provide similar flags or workflows.

Git: List Changed Files Only

For Git, the most direct command is:

git diff --name-only REVISION_A REVISION_B

Example:

git diff --name-only 1a2b3c4 5d6e7f8

That prints only the file paths that differ between the two revisions.

If you also want to know whether a file was added, modified, or deleted, use --name-status instead.

git diff --name-status 1a2b3c4 5d6e7f8

Typical output includes markers such as A, M, and D.

Git: Summary Output

Sometimes a summary is more useful than a bare list.

git diff --stat REVISION_A REVISION_B

This shows changed files plus insertion and deletion counts. It is still much shorter than a full patch and works well in reviews or release notes.

Subversion and Mercurial Equivalents

In Subversion, compare two revisions with svn diff.

svn diff -r 120:135

That shows content changes. To focus on filenames, many teams pipe or parse the summary output instead:

svn diff --summarize -r 120:135

In Mercurial, the equivalent diff uses revision flags:

hg diff -r 25 -r 30

And for just the file names:

hg status --rev 25 --rev 30

The exact output format differs, but the idea is the same: compare two snapshots and ask for changed paths rather than full hunks.

Choose Revisions Carefully

A frequent source of confusion is comparing the wrong pair of revisions. In Git, these common patterns matter:

• 'A B compares the two snapshots directly'
• 'A..B is mostly a log-range concept, not the usual diff form'
• 'A...B compares against the merge base, which answers a different question'

If you want “what files differ between commit A and commit B,” use the two explicit revisions with git diff.

Working Tree vs Revision Comparisons

Do not mix commit-to-commit comparisons with working-tree comparisons. git diff HEAD tells you what changed since the last commit in your current checkout. git diff rev1 rev2 tells you what changed between two recorded revisions.

Those are different tasks and often get confused when debugging a release or backport.

Use Script-Friendly Output When Automating Reports

If another tool needs the changed file list, prefer machine-friendly output such as --name-only or --name-status instead of parsing full patch text. That keeps release tooling simpler and avoids fragile text processing.

It also makes review automation more reliable because filenames and status codes are easier to consume than patch hunks.

Common Pitfalls

• Running a full diff when only filenames were needed.
• Using the wrong revision range syntax in Git.
• Comparing the working tree instead of two committed revisions.
• Forgetting --name-status when the change type matters.
• Assuming every version-control system uses the same revision syntax and output style.

Summary

• In Git, use git diff --name-only REVISION_A REVISION_B to list changed files.
• Use --name-status when you need added, modified, or deleted markers.
• Use summary-style options in SVN and Mercurial for the same high-level view.
• Be precise about which revisions you are comparing.
• Separate commit-to-commit questions from working-tree questions.