Nathan Gray <n8gray@xxxxxxxxxx> writes: >> Other workflows that use private tags are possible and they might >> benefit from having separate namespaces; it is just that they are not >> the workflow Git was originally designed to support. > > That makes sense. Yeah, as I said, the current behaviour aims to support a particular workflow, e.g. * "git fetch --tags" uses a built-in refspec "refs/tags/*:refs/tags/*" and that maps a tag at the remote to the same location in the refs/ hierarchy in the local repository. * "git fetch" that stores the history it fetches to local repository (i.e. uses refspec with non-empty RHS), when run without "--no-tags", fetches tags that point at commits in the fetched history from the remote and stores them at the same location in the refs/ hierarchy. and does it well. But there is nothing in Git that fundamentally forces you to follow that pattern. It is entirely plausible to enhance the former (i.e. --tags) to a bool-or-string option to let you specify different refs/ hierarchy (e.g. "--tags" would use "refs/tags/*:refs/tags/*" to map the names, while "--tags=refs/remotes/origin/tags" might store fetched tags in specified place that is different from refs/tags/), and to add a new option to specify where the auto-followed tags would be stored to enhance the latter. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html