On Mon, Feb 07, 2011 at 08:05:51PM +0100, Bernhard R. Link wrote: > > 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? Well, I believe that the best practice is that each developer has his/her own private repo and there is also a "bare" repo to which is used to share results with others. In this way, local tags are stay only inside one's private repo. If you need to fetch directly from someone working repository, you can use "git fetch --no-tags", but obviously it is not an optimal solution if you also need to fetch global tags from it, because you will have to specify them explicitly. > > > 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. Sure. I probably should have said that I'd consider only global tags in the rest of my email, because local tags should not be normally visible outside of one's repo. > And even for global tags it can be interesting to see which remote has > them, without having to manually look at all those remotes. I am not sure why it should be interesting. I mean as long as you do not have tag clashes, you should not need to know that. And if you really need to know that, you can use "git ls-remote" to check actual references. > > > IMHO, it is very confusing, especially for people whose script was > > suddenly broken by those namespaces. > > Like it was when remotes where introduced? How many people used git back then and how many people are using now? Have you forgotten what happened when the dash was removed from git commands? There was endless cry about breaking git, though all what those people need to do is to add one directory to their PATH to have git dash commands back. So, what may be okay for a young and immature project (used by a small group of enthusiasts) may be not okay for a tool on which many people rely. Most people who use git now do not read ReleaseNotes. They just install a ready package for their favorite distro and expect everything to work as before. So, I think any changes should be introduced as gradual as possible. Dmitry -- 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