What does git shortlog -sn report, and when would you use it?

## What shortlog is for `git shortlog` is `git log` output reorganised by person. Instead of a chronological stream, it prints a block per author: the author's name, then their commit subjects indented beneath it. That format was designed for release announcements — the classic "changes in this release, by contributor" section — and it remains the fastest way to produce one. ## The flags - `-s` / `--summary` — drop the subjects and print only the number of commits per author. - `-n` / `--numbered` — sort by commit count, descending, instead of alphabetically by name. - `-e` / `--email` — include each author's email address in the heading. This is how you spot the same human appearing twice under different identities. - `--no-merges` — exclude merge commits, which otherwise inflate the counts of whoever integrates branches. So `git shortlog -sn` is the commonly typed combination: a ranked tally. `git shortlog -sne` adds emails to that tally. ## Scoping it With no arguments and a terminal on standard input, shortlog summarises the current branch's history. Give it a revision range and it summarises that range instead — `git shortlog -sn v1.0..v2.0` is the per-author breakdown of a release. It also accepts the same filters as log, so `git shortlog -sn --since='3 months ago'` works. A useful mechanical detail: when no revisions are given and standard input is not a terminal, shortlog reads log output from standard input. That means `git log --oneline --no-merges v1.0..v2.0 | git shortlog` is valid, and more generally you can shape the traversal with the full power of `git log` and then hand the result to shortlog for grouping. ## Grouping by something other than the author Recent Git supports `--group=<type>`, where the type can be `author`, `committer`, or `trailer:<token>`. Grouping by a trailer is the interesting one: if your project uses `Co-authored-by` or `Reviewed-by` trailers, `--group=trailer:Reviewed-by` produces a tally of reviewers rather than authors. That turns shortlog from a vanity counter into a way to query whatever structured metadata your commit convention records. ## Identity is messy Authors are grouped by the exact author string, so `Jane Doe <[email protected]>` and `jane <[email protected]>` are two people as far as shortlog is concerned. Git's mailmap mechanism exists to fix this: a `.mailmap` file maps alternative names and addresses onto canonical ones, and shortlog honours it. Without a mailmap, per-author numbers from a long-lived repository are essentially always wrong at the margins. ## The caution that belongs in the answer Commit counts are a measure of commit-making, not of contribution. A single commit can be a rewrite of a subsystem, and a hundred can be typo fixes; squash-oriented and merge-oriented workflows produce wildly different counts for identical work. Shortlog is excellent for changelogs, for finding out who knows a subsystem, and for spotting bus-factor concentration — and it is a bad performance metric. An interviewer who asks about it is often listening for whether you volunteer that distinction unprompted. ## Where it fits Use it when the question is "who" rather than "what": drafting release notes, working out whom to ask about an unfamiliar area, or checking whether a component has exactly one contributor. When the question is "what changed", stay in `git log`.