git-fame: a table of who actually wrote the code in a repository

A table of contributions, sorted by whatever you consider the point

git-fame is a Python tool that pretty-prints the collaborators of a git repository sorted by contributions. The output is a table with one row per author and columns for hours, months, lines of code, commits, files, and a distribution column. The default sort key is lines of code, and the option list shows that it can also be commits, files, hours or months, with a --min threshold to hide the noise. A working example prints statistics for all source files in a C++ and CUDA repository, selecting the files with an include pattern and handling whitespace and line copies:

git-fame --incl '\.[cht][puh]{0,2}$' -twMC

The point of the tool is the attribution rather than the vanity. A repository's history records who wrote what, and after a decade of contributions and refactoring, the surviving code often tells a different story from the commit count.

The distribution column measures what survived

The column that makes git-fame different from a commit counter is distribution, and the README explains it as a percentage breakdown of loc, coms and fils. In the example given, the leading contributor has written surviving code in 172 of 461 files, which is 37.3 percent of all files, and the table shows the same for commits and for lines. That reading is the important detail, because a contributor with a high commit count but a low distribution percentage has touched many files without leaving much behind. The totals line above the table gives the overall picture, with total commits, total atimes, total files, total hours, total months and total loc. It is a compact way to see both the size of a codebase and how concentrated its authorship is.

Five installation routes, including a container

git-fame is distributed through most of the usual channels, and the README lists each with its command. The PyPI stable release is a plain pip install:

pip install git-fame

There is also a development install straight from GitHub, a conda-forge package, a Snapcraft snap, and a Docker image. The container route is worth noting because it removes the need for a local Python setup, and the Dockerfile shows a minimal image built on python:3.13-alpine with git added and the wheel installed, with the entrypoint pointing the tool at a /repo directory:

docker run --rm casperdcl/git-fame --help
docker run --rm -v "/local/path/to/repository:/repo" -u "$(id -u)" casperdcl/git-fame

The volume mount with the host user id is how you keep the ownership of the files in the repository correct after a run. The project also generates shell completion scripts with git-fame --print-completion <shell>, which the README notes works with git-fame itself but not with the git alias.

Cost estimates are models, and the model changes the line count

The --cost option adds an effort estimate, and it comes with a side effect that is easy to miss. The methods are month(s) for person-months using COCOMO, hour(s) for person-hours based on author times, and cocomo for person-months. The README states that specifying --cost alters the --loc default, implying insertions for COCOMO and insertions plus deletions for hours. So the choice of cost method quietly changes what the lines column means, and two runs that differ only in that flag are not comparable. The --loc option itself selects surviving lines, insertions or deletions, with ins,del counting both. For a review of how much code arrived over time rather than how much survives now, insertions are the honest measure.

Filtering, date ranges and aggregating several repositories

The option set handles the practical cases. --incl and --excl select files by regular expression, or by exact comma-separated match when -n or --no-regex is passed, in which case a comma can be escaped for a literal. --since and --until restrict the history to a date range and accept both absolute dates such as 1970-01-31 and relative ones such as 3.weeks. --branch selects a branch or tag, defaulting to HEAD. The positional argument is the git directory, which may be given more than once to aggregate across repositories, and -R or --recurse finds repositories and submodules within a directory. The tool can also run from inside a Python shell or script:

>>> import gitfame
>>> gitfame.main(['--sort=commits', '-wt', '/path/to/my/repo'])

The repository root adds a .mailmap, which matters for attribution, since it lets git-fame merge commits made under different names or emails into one contributor row.

A hosted service for public repositories, and the licence terms

There is a live server for public GitHub repositories at git-fame.cdcl.ml, with a URL pattern that takes an owner and a repository, and its API documentation describes the parameters. The README mentions a sponsorship perk, namely that the watermark is removed and some non-default options such as branch, auth, show and ttl are unlocked for sponsors. On the licence, the package metadata declares MPL-2.0 and the repository root holds a LICENCE file, while the repository listing shows the licence as one GitHub cannot classify, which is worth checking against the file itself before redistributing anything. The release history shows steady work: v4.1.0 and v4.2.0 both on 2026-09-04, v4.2.1 on 2026-09-07, and the last push was on 2026-10-05. The project also registers a Zenodo DOI, which matters for anyone citing it as a piece of software.

Editorial conclusion

git-fame suits a team doing due diligence on a repository it has just inherited, or a maintainer who wants to see which files still carry one person's work after a decade of churn. It does not suit anyone who wants a productivity score, since the numbers come from git history and survive exactly the mistakes git history records. Before trusting a table, run it with --loc ins rather than the default surviving lines, and check the --cost method you pick, because the person-month figure is a model estimate rather than a measurement.

Frequently asked questions

Official sources

1. casperdcl/git-fame on GitHub
2. Issues
3. Project website
4. README
5. Releases