Introduction
“Large commit” can mean two different things in Git: a commit that changes many lines, or a commit that introduces large blob objects into the repository. Those are related but not identical, so the first step is deciding whether you care about review size, repository bloat, or both.
Measure Large Diffs With git log
If your goal is to find commits that were hard to review because they changed many files or lines, use diff statistics.
git log --shortstat --oneline
That prints each commit followed by a short summary such as files changed, insertions, and deletions. For a more focused view, include the hash and sort manually.
git log --pretty=format:'%H %s' --shortstat
This approach is useful when you want to identify oversized code review changes, squashed refactors, or vendor drops. It does not tell you how much storage the commit added to the repository packfiles.
Find Large Stored Objects
Repository size problems usually come from large blobs, not from line counts. A binary file added once may barely show up in diff stats but still make clones expensive.
To find the largest objects reachable from history, list object IDs, inspect their sizes, and sort them.
git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \ | awk '$1 == "blob" {print $3, $2, $4}' \ | sort -nr \ | head -20 ``` This answers a different question: which blobs consume the most storage. Once you see a suspicious object, you can determine which commits introduced or referenced it. ```bash git log --all -- path/to/large-file.bin ``` If the file was renamed, add `--follow` when inspecting a single path. ## Connect Blobs Back to Commits Git stores blobs separately from commits, so a commit does not have one intrinsic “size” field. To trace a large blob back to its introduction point, inspect the path history and the commit that first added it. ```bash git log --diff-filter=A -- path/to/large-file.bin ``` If you already know the commit and want to see how big the patch was, use `git show --stat` or `git show --numstat`. ```bash git show --stat <commit> git show --numstat <commit> ``` `--stat` is readable for humans. `--numstat` is easier to process if you want exact counts. ## Use the Right Metric for the Job If your CI is slow because engineers keep merging thousand-line changes, diff stats are the right metric. If clones and fetches are slow because someone committed build artifacts or media files, blob size analysis is the right metric. Teams often confuse the two and end up looking at the wrong report. A commit with one large compressed file may look tiny in text diff output. A commit that reformats the whole codebase may look huge in diff stats but barely affect long-term repository size. ## What to Do After You Find Them For recent history, the fix may be social rather than technical: smaller pull requests, better review discipline, and avoiding generated files. For repository bloat already committed to history, you may need a history rewrite with tools such as `git filter-repo`. That is a coordination task, not just a command-line trick, because everyone must realign to the rewritten history. For a broader health check, teams sometimes run repository sizing tools on top of these commands so growth trends are visible before the repository becomes painful to clone. The core investigation still starts with the native Git plumbing shown above. ## Common Pitfalls - Assuming “large commit” always means high disk usage, when it may only mean a big textual diff. - Looking only at `git log --stat` and missing binary blobs that dominate repository size. - Treating commits as if Git stores a single commit size number, when storage is really about underlying objects. - Rewriting shared history to remove blobs without coordinating with other contributors. - Ignoring generated artifacts, which are a common source of both large diffs and repository bloat. ## Summary - Decide first whether you care about review size or repository storage size. - Use `git log --shortstat`, `--stat`, or `--numstat` to find large patches. - Use `git rev-list --objects --all` with `git cat-file` to find large blobs. - Trace suspicious paths back to commits with normal Git history commands. - The best fix depends on the problem: smaller commits for review issues, history cleanup for blob bloat.
