Maybe a better way to track the release history of a Git repo

While working on a large Git monorepo at ZipRecruiter, the deployment tooling created thousands of tag refs like refs/release/stg.www.our-app-<timestamp>-treesha-<hash>, embedding tier, app, timestamp and tree ID in the ref name. That proliferation made many Git operations slow because packed-refs had to be scanned repeatedly, cluttered common command outputs, and left metadata encoded only in names without Git-level enforcement. Tags also proved a poor audit mechanism: they are mutable and answering simple questions like “when was the last production deploy of app X?” required filtering and sorting a huge list of refs.

The proposed solution replaces many per-release refs with one ref per (tier, app) that points to a chain of metainfo commits. Each metainfo commit has two parents: the prior metainfo commit and the actual release commit; creation uses git commit-tree and an update of refs/release/<tier.app>. Git’s native history traversal then enumerates releases efficiently (git log on the ref), lets HISTORY^2 name the released commit, supports diffs and rollbacks, and can store structured metadata in commit messages or trees. This leverages Git’s optimized commit traversal instead of thousands of refs; the idea was proposed in 2019, wasn’t adopted, and the author notes there may be unanticipated drawbacks.