Introduction

Git can show the commit history for a subdirectory by combining git log with a pathspec. The core trick is to put -- before the path so Git knows you are filtering history by path rather than passing another revision argument.

Basic Directory History

The simplest command is:

git log -- path/to/subdir

You can also be more explicit:

git log -- ./path/to/subdir

This shows commits that affected files inside that subdirectory. A commit can still appear even if it also changed other parts of the repository, because Git is filtering by whether the commit touched the path, not by whether the commit was exclusive to that path.

Why the -- Matters

The -- separator tells Git that everything after it is a pathspec.

git log -- src/api

Without it, Git can misinterpret the path as a branch name, revision, or other argument, especially in repositories where names overlap.

Make the Output Easier to Scan

Directory history becomes easier to read with a compact format.

git log --oneline -- path/to/subdir

Or add author and date information:

git log --pretty=format:'%h %ad %an %s' --date=short -- path/to/subdir

This is useful when you are auditing ownership or investigating when a directory changed over time.

Show the Actual Changes Too

If you need the diff for each matching commit, add -p.

git log -p -- path/to/subdir

If you want a lighter summary, --stat is often easier to scan:

git log --stat -- path/to/subdir

That shows which files in the subdirectory changed and how many lines moved without dumping the full patch for every commit.

Limiting the History

You can combine path filtering with all the normal git log options.

git log -n 20 --author='Ava' --since='2025-01-01' -- path/to/subdir

That makes it easy to answer narrow questions such as:

• who touched this area recently
• what changed before a release
• which commits from one developer affected this directory

Renames and Directory History Caveats

This is the subtle part. Git tracks content through commits, but directory rename history is not as straightforward as file rename history. For a single file, git log --follow -- file.txt can help across renames. For a directory, there is no direct equivalent that always reconstructs "the old name of this whole folder" automatically.

That means if a subdirectory was renamed, you often need to inspect older names explicitly.

git log -- old/path/to/subdir
git log -- new/path/to/subdir

For files inside the directory, --follow can still be useful one file at a time.

A Useful Investigation Pattern

When debugging a problem in one area of a monorepo, a good pattern is:

1. start with git log --oneline -- path/to/subdir
2. inspect a suspicious commit with git show <commit>
3. narrow further to one file if needed

Example:

git log --oneline -- services/payments
git show abc1234 -- services/payments

This is often faster than scrolling through full-repository history and mentally filtering irrelevant changes.

Common Pitfalls

The biggest pitfall is forgetting -- before the path. Git may still run, but the meaning of the command can change in confusing ways.

Another issue is expecting only directory-exclusive commits. Git shows commits that touched the path, even if they also modified files elsewhere in the same commit.

Developers also assume --follow works cleanly for entire directories. In practice, rename tracing is much more reliable for single files than for directory histories.

Finally, be careful with relative paths. Run the command from the correct repository root or give a path that makes sense from your current working directory.

Summary

• Use git log -- path/to/subdir to show commits that touched a subdirectory.
• Put -- before the path so Git treats it as a pathspec.
• Add --oneline, --stat, or -p depending on how much detail you need.
• Commits appear if they affected the directory, even if they also changed other files.
• Directory rename history is not as seamless as single-file --follow history, so older paths may need separate inspection.