[tremon]

That's true, but git also doesn't have tags that apply to a subset of the repository tree. You can easily check out `project-b/v1.2.0` and build project-a from that tree. Of course, the answer to that is "don't do that", but you still have the weird situation that the source control implementation doesn't match the release workflow; your `git describe` example is but one of the issues you will face fighting the source control system -- the same applies to `git log` and `git diff`, which will also happily give you information from all other projects that you're not interested in.

For me, the scope of a tag should match the scope of the release. That means that a monorepo is only useful if the entire source tree is built and released at the same time. If you're using a monorepo but then do partial releases from a subtree, you're using the wrong solution: different repo's with a common core dependency would better match that workflow. The common core can either be built separately and imported as a library, or imported as a git submodule. But that's still miles ahead of any solution that muddles the developers' daily git operations.

[WorldMaker]

I understand the low level details of why tags don't work that way and why git leaves that "partial release" or "subtree release" as a higher level concept for whoever is making the tags in how they want to name them.

I know there are monorepo tools out there that do things like automate partial releases include building the git tag names and helping you you get release trees, logs, and diffs when you need them.

I think a lot of monorepo work is using more domain specific release management tools on top of just git.

Also, yeah, my personal preference is to avoid monorepos, but I know a lot of teams like them and so I try my best to at least know the tools to getting what I can out of monorepos.

[tremon]

Do you have any examples of tooling like that, providing the monorepo tiling on top of git's porcelain so to speak? I had assumed that most of such tooling is bespoke, internal to each company. But if there's generic tooling out there, then I agree, it's useful to know such.