Johan Herland <johan@xxxxxxxxxxx> writes: > I don't see how the separate namespaces cause problems here. Also, I don't > know what you're proposing instead, or indeed what other organization of > tags would lead to less confusion. I'm not against the idea, but one drawback of the separate namespace is that it introduces complexity for the user. In the common case, where the user may fetch the same tag from various sources, there will still be several refs (probably listed by "git tag" ?), and this may confuse the user. Another question is what happens when you push. With branches, fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY. This asymetry between push and pull works well because most of the time, if we have a origin/XXX branch, we also have XXX (with origin/XXX as upstream). For tags, it's clearly different. If I have origin/v1.7.4, I don't see much reason to have _also_ v1.7.4 as a local tag. And if I have only origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from it will get origin/origin/v1.7.4, and so on. So, my feeling is that the "separate namespace" should not be automatic. For example, today, git.git repo contains tags like v1.7.4 and others like gitgui-0.13.0, which is clearly a handmade namespace, where a real namespace would be better. That would make a lot of sence to me if Junio had something like [remote "git-gui"] url = ... fetch = +refs/heads/*:refs/remotes/git-gui/* fetch = +refs/tags/*:refs/tags/remotes/git-gui/* or whatever other syntax, so that git-gui's tags be automatically fetched into the right namespace (with no warning in case of duplicate). But OTOH, I don't want to have several namespaces in my git repo even if I configure several remotes to fetch from. In this case, duplicate tags are just redundancy if they point to the same object, and a real conflict I want to know about immediately otherwise. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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