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

A monorepo accumulated thousands of deployment tags like refs/release/stg.www.our-app-YYYY... that encoded tier, app, timestamp, and tree hash in their names. Those many refs slowed operations because Git had to search packed-refs for every ref resolution, cluttered common commands, and simply encoded metadata as a naming convention rather than as first-class, immutable data. Tags are mutable and deleting or inserting tags breaks the audit trail. Common questions - when was the last prod deploy of an app, or what was the version immediately before the most recent - required filtering and sorting the entire tag list, which became impractical at scale.

The proposed alternative represents each (tier, app) as one ref pointing to a chain of metainfo commits. Each metainfo commit has two parents: the previous metainfo commit (first parent) and the actual release commit (second parent). Metainfo commits store release metadata either in the commit message/trailers or in a dedicated tree; their creation time is the release time. New releases are created with git commit-tree -p <old-meta> -p <release-commit> ... and the new meta SHA is pushed to the single ref. Fetching and querying (git fetch ref:HISTORY; git log HISTORY; HISTORY^2 is current release; HISTORY~N^2 is N releases back) then leverages Git’s native history traversal for efficient searches, diffs, and rollbacks while keeping only one ref per deployment target. The idea was proposed in 2019 but was not widely adopted and could have unforeseen drawbacks.