Marc Branchaud [off-list ref] writes:
Tags don't become "official" until they're published according to the
project's process. For us git users, that means the tag appears in
git.kernel.org/pub/scm/git/git.git. A tag that appears somewhere else can
have all sorts of meanings, but I don't think "official" could be one of them.
I think you are essentially saying the same thing.
Think of hiding the unofficial tags to refs/private-tags by "interim
maintainer" (or public at large for that matter); they won't be published
automatically, unless the publisher decides to publish "according to the
project's process."
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.
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.
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