| Mark Waite, I have the "Fetch tags" behavior enabled, but it doesn't actually match my use-case, which is looking for deeper history than just the most recent tag parent of the current branch. It does fetch all of the tag refs, but it doesn't fetch any additional pieces of the commit graph. My use case would require that it also fetch enough additional commit-graph history to be able to determine the ancestry from the current branch back to every tag. This is because my use case is a multi-product repository, with tags using a "namespace" prefix along the lines of "product_foo-vN.N.N". This combines with the fact that our build pipeline builds the latest version of every product in the same job. We ultimately use a git describe HEAD --tags --match 'product_foo-v*' to determine the tag parentage of the current branch for that part of our full version string. So our clone would have to go all the way back to the oldest supported product's most recent version, which in the worst case could be almost the entire repository history - not really something that we should be doing in a regular build cycle. All this has led me to realize that our dynamic multi-product versioning based git tags isn't really a practical solution, and given our current repository structure and usage, we should just back off to manually-maintained per-product version numbers, as is normally done in most any packaging system. All that said, it is still true that while there exists a behavior to fetch all tags, it doesn't really leave the user with "usable" tags without the commit graph necessary to trace the branch back to them. |
