Re: Tags

[Dan Holmsand <holmsand@gmail.com>]

Linus Torvalds wrote:
> And a "tag ref" thing is really nothing more (and nothing less) than a
> branch. 

I'm guessing that this is the root of the confusion here. To you, and to 
git, a tag is just a another branch. And a tag object is pretty much a 
specialized commit object, that can't have children and only one parent.

But people seem to *expect* tags to be connected somehow to a specific 
repository. Or, rather, to a specific branch.

That's why people want e.g. cogito to get "all the tags" from 
torvalds/linux-2.6.git when they cg-pull.

 From git's point of view, that doesn't really make any sense; it's like 
saying that you should pull all the branches from a specific branch. But 
from a practical point of view, it *does* make sense if you hold the 
view that tags are connected to a branch, and that you should be able to 
diff against v2.6.12 as soon as you've pulled the latest head.

So why not add tags to the branch itself?

It should be pretty straightforward: just make git look for tag refs in, 
say, a .gittags tree in the current HEAD. The whole thing would pretty 
much as if you've symlinked .git/refs/tags to .gittags in the current 
working tree, except that tag refs would have to be read directly from 
the repository.

That way, tag refs could be handled pretty much just like any other 
git-managed file: they can be added, deleted, changed, merged, 
committed, etc. We could track their history, and see who tagged what 
and when.

And tags could easily be signed and contain arbitrary text, just like 
the present day tag objects, as long as they start with a sha1 ref.

This way, a git branch could have public, shared tags, with a minimum of 
hassle. No special-casing needed for storage or transfer.

And there would be no room for conflicting tag names (but you could 
easily use the same name in different branches, just as any file can 
differ in content between two branches).

It might be useful, though, to add some syntax for "tag in a specific 
branch", say <branch-name>@<tag-name>.

The present tagging mechanism should be kept. It is useful for private 
tagging, and may be useful for signalling that "this is a branch that is 
unlikely to change".

So, am I missing something obvious here?

/dan