That doesn't seem reasonable to me. You'd be using Git for persistence concerns that are not directly related to source code management.
"Environment X had commit a1b2c3d deployed at 1970-01-01T00:00:00Z" is all you need to store, and I don't see why you'd want to do that in the repo itself. Commit a1b2c3d exists regardless of where or when it's deployed.
Store that data in the thing that handles the deployments.
You can use git describe's output to exactly name a commit. You can also use annotated tags to tag semver releases or marver (Marketing Version) releases and if you output the git describe to users that care about semver or marver they see confidence in your deployment system when you deploy exactly a tag versus deploy something like a hotfix after it. But git describe is also useful for lower environments because it will have useful output when not directly on a tag.
(ETA: For a monorepo you can still use semver/marver annotated tags with `git describe --match subproject/` to use a tree structure for tags.)
For example it's quite readable when deployment order matches the commit order, but it gets problematic when e.g. the deployed version is rolled back to a previous version.
It also gets messy as environments are added, or even worse you have to manage customer-specific deployments.