Nineteen extensions decide what gitinspector counts, and lines are not contribution

Nineteen extensions decide what counts, and the default is source code only

The filtering feature is one line long and it is the most consequential thing in the document. Results are filtered by extension, and the default list is nineteen of them, all of them source languages: Java, C and its variants, headers, PHP, Python, a shader language, Ruby, JavaScript, SQL, Go, Swift, TypeScript in both flavours, Rust, and Groovy. The prose says it plainly: by default the analysis includes only source files. So a documentation change, a build script, a configuration file, a notebook, a test fixture, and anything generated are all outside the measurement unless you ask for every filetype found in the repository, which the feature list says it can do. There is also a flag for reporting violations of code metrics, which is the feature that makes it a grading instrument rather than a curiosity: you can hold a course to thresholds.

The release history has a decade in it

Three releases are visible and the gap between the first two is the story. A patch release dated 2016-02-03. Then nothing for ten years. Then a minor release on 2026-09-09 and a patch on 2026-09-25, sixteen days apart. The manifest in the repository is already a development version past the newest tag, which is a normal way to live. What is not normal is the shape: a tool that universities use for grading sat unversioned for a decade and then shipped a minor and a patch in the same month, so anyone who pinned to the 2016 build has something ten years older than anything the project has published since. The copyright on the packaging file runs from 2013 to the present year, so the code itself has been touched throughout. The last commit to the tree is dated 2026-10-01.

The Python version claim has not been revisited in a decade

One feature bullet states that the tool runs on Python 2.7 and on Python 3.5 and later, and then says to see a requirements file in the documentation directory for the supported versions. Both of those interpreter versions reached the end of their support long before the current release, and the phrasing of the bullet is the phrasing of a project written around 2016. The deferral to a separate file is reasonable practice, and the file may well be current. What the document does not do is state a floor anywhere, so a reader has to go looking. The one place the runtime is pinned properly is the container, which uses a major-version-only Python tag on Alpine, so the interpreter that runs the tests in the image is whatever the newest release of that tag happens to be.

The npm package's entry point is a Python script

One of the four distribution channels deserves a second look. There is a package on the JavaScript registry whose name matches the tool, and the install instruction is a global install of that name. Its manifest declares the main entry point to be the Python script at the repository root, and its bin mapping points at the same file. So the registry package is a wrapper whose payload is a Python program, and there is no JavaScript implementation. What the registry is really for is the release pipeline: three small development dependencies, and a release script that substitutes the version into a commit, tags it, pushes, publishes to the registry, and pushes the tags, with a separate beta path that adds a distribution tag. The manifest also declares that a test script exists which prints an error and exits non-zero, so the obvious way to run the tests does not work and the real suite lives elsewhere.

The Debian packages this project publishes are the unofficial ones

The packaging section is admirably precise about a distinction most projects blur. The Debian packages attached to the project's own releases are described as unofficial and very simple, generated automatically by a tool that builds source packages into binary ones, and the root carries both that tool's configuration and a packaging directory. The official Debian packages, the ones you would actually install with the package manager on a Debian-derived system, are maintained by a named individual and their status is tracked on the Debian package tracker. So there are two Debian packages with the same name and only one of them is blessed, and the readme tells you which. Add the package index, the registry wrapper, and the container and you have four channels, three of which are officially the project's own.

The container trusts the mount point and nothing else

The container file is short, and running it means mounting a repository into the image with two commands:

docker build -t gitinspector .
docker run --rm -v "$PWD:/repo" gitinspector -f py -T

One of the lines in the image file is the best piece of engineering in the repository. The tool is normally run by mounting a repository into the container, and the host's repository is owned by the host's user rather than by the account inside the image, which modern git refuses to read from unless the directory is declared safe. The usual fix is to declare every directory safe, which defeats the check everywhere. This image does not do that: it adds the mount point as safe, and adds it again with a wildcard for its children, and a comment explains that only the mount point is trusted and anything else in the image keeps the check. The rest of the file sets an encoding, installs git, copies the package and the entry script, and sets the working directory to the mount. The base image is tagged with a Python major version only, so the interpreter floats.

The named successor is a rewrite, and the project says so

There is a Forks section and it points at the successor rather than a compliment. The fork started as an extension of this tool and has since been rewritten from the ground up, offering a graphical interface alongside the command line, output in HTML and Excel with blame information per file, and stand-alone applications for two desktop systems, with its own documentation host. So the advice for someone starting today is not to use this tool but to look at that one, and the project is candid enough to say so. What remains here is the command line tool, which for a grading workflow is still the thing you want, because it runs in continuous integration and emits machine readable output, which the graphical successor with its own applications may not.

Editorial conclusion

gitinspector fits a course or a team that wants a per-author activity breakdown rather than a judgement, and the timeline view is genuinely more informative than the totals. Check four things. What you are actually measuring, because the tool reports lines of code per author and that is a size metric, not a contribution metric, and the project itself says its purpose is grading. What is excluded by default, because only nineteen source extensions count unless you change the filter, so documentation, tests written as data, configuration, notebooks, and generated files are invisible. Which version you are on, because the release history has a decade-long hole in it and the manifest is already a development version past the newest tag. And how you install it, because four channels exist and the one the project publishes to the Debian archive is explicitly unofficial.

Frequently asked questions

Official sources

1. ejwa/gitinspector on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases