Johan Herland <johan@xxxxxxxxxxx> writes: >> 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. > > Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the > origin remote, so there's no point in trying to push it back. On the other > hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should > (assuming this is intended to be a public tag) consider pushing it to the > "origin" remote, thus causing origin/v1.7.4 to appear in your repo. (I made a bad choice by repeating "origin" several times) What happens if I pull from "remoteA" and then push to "remoteB"? With branches, I'd create a local "master" from remoteA/master, and then push my local "master" as "master" on remoteB. People looking at my repository remoteB won't notice where it's comming from because it had to be local for me at some point. With tags, we probably don't want to force people to explicitely create local tags to be able to push them. Take the example of the interim maintainer cited somewhere else in this thread. If Shawn fetches from Junio, he'll get a junio/v1.7.4 tag, and on my side, I do not want to end up having shawn/junio/v1.7.4, especially if this means that people fetching from me would end up with a me/shawn/junio/v1.7.4 ... > As Nicolas mentioned elsewhere in the thread, having separate tag namespaces > does not prevent us from also warning about ambiguous tag names on > fetch. It does not "prevent", but I think it makes it a mis-feature. Distinct namespaces (as opposed to warning/errors on duplicate at fetch time) are useful when the same short name can refer to several things (like v1.7.4 Vs gitgui-v1.7.4 (which doesn't exist yet), and then it's not a problem to have twice the same short name. -- 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