git log --shortstat --oneline

git log --pretty=format:'%H %s' --shortstat

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.