I do want to note as well that if that tag isn't found, it should default to the real tag, because, for example, the sha may not need to be included in the docs, if e.g. a tool becomes commonplace that will automatically discover a git dep's sha from the tag and add it to your deps file (this being a tool I intend to write in the coming days)

Ya @suskeyhose, that is an important detail.

On a more general note that might help with discussions like this one, I wonder if we should enable GitHub discussions on the cljdoc repo. For pieces of work like this one, the GitHub issue could act as evolving design doc that summarizes outcomes/decisions from a GitHub discussion. I notice that @borkdude will use sometimes use GitHub discussions in this way for feature work. https://github.com/babashka/babashka/issues/778. Note that this kind of departs from cljdoc’s current strategy of https://github.com/cljdoc/cljdoc/tree/master/doc/adr. But I do like the idea of avoiding commit churn when hashing out ideas. Perhaps a design doc could be committed (that might just point to the GitHub issue?), after we have hashed out a plan. Whatcha think @martinklepsch?

That sounds like a great idea!

Also probably a great tool to handle requests around failing builds

Great! @martinklepsch when you have a spare moment you can enable discussions on the cljdoc repo via Settings->Options->Features->Discussions.