On Mon, 7 Feb 2011, Junio C Hamano wrote: > As I said in my message, it feels awkward to use refs/private-tags for > tags everybody uses for his or her own purpose, so by swapping the roles > of namespaces around, we would be able to use refs/tags for private ones, > and refs/remotes/origin/tags for the ones that came from upstream. But > then if you fetch/pull from a third party (including the "interim > maintainer"), it feels wasteful to get full set of tags that you have in > the origin namespace anyway replicated in refs/remotes/interim/tags. Why so? At least you get to know if that particular remote has a particular tag that may also exist elsewhere. And if you decide to drop one remote source with all its tags from your local repository, then the remaining one(s) still have relevant tags available. > And that is what bothers me---not the waste itself, but I have this > nagging feeling that the wasteful duplication is an indication of > something else designed wrong. We do have "wasteful" duplicated references all over the place, such as when two directories (tree objects) contain the same file content (refer to the same blob object). But no one feels like this is wasted duplication as those two directories end up using the same single blob object even if in the working directory you get twice the content. Here this is the same thing. You have multiple handles to the same tag which are distributed across different remote repositoryes you are tracking. The name on the tag may be found in many places, and even under different names. But there is still only one actual tag object. If you have 3 remotes sharing the same tag then you know that the tag cannot be garbage collected until all three remotes have been removed from your repository. Simply storing snapshots of the tag state per remote repository is simple and allow for smarter processing on top, which is in agreement with the design philosophy for the rest of Git. Nicolas -- 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