* Dmitry Potapov <dpotapov@xxxxxxxxx> [110207 01:07]: > There are two sorts of tags: > - local tags, which are never intended to be shared with others but used > by users to mark some points in the working repository. > - global tags, which are just _social_convention_ about what the current > project considers as official versions. Without social convention, they > make no sense. >[...] > It seems you do not understand the problem that I am trying to say all > way along: there is more than one repo from which I fetch tags, and > because they are belong to the same project, they should be in the same > namespace. So there are those "local tags", which are not to be shared with others. Does that mean an user should always have two repositories, one with those tags for themselves and one without those tags for each other? And the private one should always be the one that does the push and fetch (as issuing a a fetch in the public to get something from the private will also get all those tags)? > > Granted, if we leave all tags in a single namespace, I can still work around > > this by manually futzing with the configured refspecs to create ad hoc > > namespaces. But I _really_ hate it when I'm forced to hack around the tool, > > because the tool thinks it "knows better". > > I believe that the right interface when the common case is simple, but > an uncommon case is still possible to handle. I don't think that > currently git meets this criterion, but making tag namespaces based on > the remote name strikes me as a really bad idea. Tags are attributes of > a project and not particular remote. Global tags are. Local tags are not. And even for global tags it can be interesting to see which remote has them, without having to manually look at all those remotes. > IMHO, it is very confusing, especially for people whose script was > suddenly broken by those namespaces. Like it was when remotes where introduced? > So, IMHO, the proper solution should be ability to specify the desired > namespace for any remote repository, like this: > > remote.<name>.tagNameSpace = foo > > So, those who want to have many namespaces should be able to that > easily, but forcing multiple namespaces on those who have a single > namespace semantically is simple wrong. Not to mention that it breaks > existing scripts for no good reason. I'd consider it more logical to have remote tags and a config to automatically make local copies of remote tags. (With whatever default people consider proper). Bernhard R. Link -- 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