(resend without HTML part; I apologize for the inconvenience) On Sunday 06 February 2011, Matthieu Moy wrote: > 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. If the user is confused by putting remote tags in separate namespaces, then the user is likely also confused by the current practice of putting remote _branches_ in separate namespaces. My point is that by strictly delineating the boundaries between what is local and what belongs to a given remote, I hope we could help some newbies past the local vs. remote confusion that often manifests itself when migrating from a centralized VCS to a DVCS. > 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). I look at it differently: "fetch" is for information discovery (i.e. "I want to know what's happened on the remote"), while pull/push is about making real changes to local/remote branches. > 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. > 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. As Nicolas mentioned elsewhere in the thread, having separate tag namespaces does not prevent us from also warning about ambiguous tag names on fetch. With separate namespaces, you could probably implement such a warning more easily as a hook, instead of hacking the fetch code directly. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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