From: Linus Torvalds Date: Sat, 02 Jul 2005 22:17:07 GMT Subject: Re: Tags Message-ID: In-Reply-To: <42C70A5B.9070606@zytor.com> On Sat, 2 Jul 2005, H. Peter Anvin wrote: > > OK, so let me retell what I think I hear you say: > > - Store all the tags in the object store; they may conflict. No. They cannot conflict. A git "tag object" cannmot conflict in any way. It is just a generic "pointer object", and like all other objects, it is defined by its contents, and there are no "conflicts". If two people have exactly the same pointer, they'll just have the same object - that's not a conflict, that's just a fact of life with content-addressable filesystems. The git "tag object" contains a suggested symbolic name, but that actually has no meaning except as being informational. So for example: [torvalds@g5 linux]$ git-cat-file tag v2.6.12 object 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab type commit tag v2.6.12 This is the final 2.6.12 release -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCsykyF3YsRnbiHLsRAvPNAJ482tCZwuxp/bJRz7Q98MHlN83TpACdHr37 o6X/3T+vm8K3bf3driRr34c= =sBHn -----END PGP SIGNATURE----- here the "symbolic name" is "v2.6.12", but that's purely informational, and nothing at all cares if a million people have made their own tags that have that same tag-name. The git _object_ is: [torvalds@g5 linux]$ git-rev-parse v2.6.12 26791a8bcf0e6d33f43aef7682bdb555236d56de and that object name is going to be unique (modulo hash collissions) > - Let each source user have a set of refs, and provide a method for the > end user to select which refs to get. Right. Let users have any damn refs they want. They may be refs to tags objects, but they may just be direct refs to the commit. The tag object really has no meaning to git, except it allows signing. That's really the _only_ thing a tag object does: it introduces trust. There's no other reason to ever use one, really. And a "tag ref" thing is really nothing more (and nothing less) than a branch. It's a 41-byte filename, although if you actually were to have a "gitforge" deamon, it could also be just the raw 20-byte SHA1 in a database. Let people have their own refs, and have some good way to create them and delete them, and copy them from others (and refer to other peoples refs - one common usage might be "I want to merge with that other users ref 'xyzzy'". Note that the .git/refs/tags/xxx files are _literally_ treated exactly the same as the same files under "heads". Or under "mydir". Git really doesn't care, it's purely syntactic sugar. To git, a ref is a ref is a ref. It just refers to an object, and it's nothing more than a way to specify some random SHA1 at any time. > In other words, the only way (other than knowing what GPG keys to trust) > to distinguish between your "v2.6.12" and J. Random Hacker's "v2.6.12" > is that the former is referenced by *your* refs as opposed to JRH's > refs. This also means the refs cannot be uniquely rebuilt from the > object storage. Right. All the refs are personal and "fleeting" - some refs are actively changed all the time (branch refs - aka "heads" - get updated when you update the branch). Tags are really the same way in all technical ways, and the only real difference between a "branch ref" and a "tag ref" is your _expectation_ of them - one you expect to be mostly stable, the other you expect to be updated with development. _Technically_ there's no difference between the two, though. (And you might also change tag contents occasionally. One reason might be a bug and you decide to re-tag something else. But a more common reason might be because you want to have tags like "latest" that don't actually update with development, but they update with some other event, like a release event or some automated test cycle completion or something like that. So tags aren't _immutable_ even from an expectation standpoint, it's just that they tend to change _less_). Now, from tag _objects_ (as opposed to tag refs) you _can_ build them if somebody created a tag object, and you have the signature so that you can re-associate the tag-name with the person. But you should consider that a pretty heavy and unusual case. The normal case is that you just want to back up peoples refs. They're like a part of a personal ".gitrc": you could equally well think of them as "these are my shorthands, because I don't want to talk about 40-digit hex numbers all the time". It's nothing more than a personal address book, really. Linus