git-harvest

Harvest a CHANGELOG from your Git history.

git-harvest turns the commits you already write into a CHANGELOG.

Made with Anthropic Claude. The implementation and the documentation were written by Claude, working to the direction and review of the author, with whom every design decision rests. Each commit names the model in a Co-Authored-By trailer, so the record is per change rather than only here.

Status

Early, but working end to end. Four subcommands cover both passes: init, scan, assemble and render. RON is the only fragment and CHANGELOG format so far, the release version and date are supplied on the command line, and there is no forge integration yet. The repository holds the full project scaffold — manifest, licence, continuous integration and the conventions harness.

How it works

Two passes, four subcommands.

git harvest init writes a starter CHANGELOG.ron carrying the default configuration: the commit-subject delimiter, the grammar, the bucket vocabulary and the renderer. It refuses to overwrite an existing file without --force.

git harvest scan, run on a feature branch, reads that branch's structured commit subjects — by default Bucket ::= entry, for example Added ::= a new option — and writes them to a RON fragment under changelog.d/, one file per branch. Only commits absent from main are read, and merges are skipped. The grammar is configurable.

git harvest assemble <version> folds every fragment into a new section of CHANGELOG.ron, stamps it with that version and the release date, inserts it in descending version order, and deletes the fragments it consumed.

git harvest render writes a Keep a Changelog Markdown file from the released sections of CHANGELOG.ron.

git harvest licences reproduces the verbatim licence notices of git-harvest and every dependency it ships for the platform it was built on, harvested at build time by list-my-licence. Pass a crate name to narrow the report to one package, or --format <text|markdown|dep5> (default text) to choose the rendering. The same harvest also refreshes the committed THIRDPARTY.md and debian/copyright on every compile, covering every platform the source can be built for, not only the one it was built on.

Because the binary is named git-harvest, Git runs it as a subcommand: git harvest init, git harvest scan and the rest work with no further setup.

Assembling release notes is the tool's job; version bumping stays with each repository's own release workflow.

Man pages

Git looks for a git-harvest.1 man page whenever --help is passed to a subcommand — git harvest --help runs git help harvest, which expects that page on MANPATH, and fails if it is not installed, even though git harvest -h and the binary's own --help still work without it. Every subcommand's page is generated from the CLI's own definitions and ships as its own man-pages.tar.gz asset on each GitHub Release — installed by a .deb automatically, or by hand otherwise, e.g. into ~/.local/share/man/man1:

mkdir -p ~/.local/share/man/man1
tar -xzf man-pages.tar.gz -C ~/.local/share/man/man1 --strip-components=1
mandb ~/.local/share/man 2>/dev/null || true

Requesting other platforms

Considering the impressive variety of ecosystems and architectures, it is not impossible that some configurations are not yet provided with precompiled binaries and/or packages. Users who find their respective ecosystem and/or architecture missing are thus invited to submit a brief issue to request support for that particular configuration. All ecosystems and architectures are welcome — they just need to be asked for such that they can be supported, eventually.

Licence

GNU General Public License v3.0 or later. See LICENCE for the full text.