Re: Tags

["H. Peter Anvin" <hpa@zytor.com>]

Linus Torvalds wrote:
> 
> Note that the fact that you use a common object store does not mean that 
> everything should be common.
> 
> I still contend that tags and branches and things like that should be 
> personal. A "gitforge" thing should _not_ try to unify tags. Instead, give 
> people their own private area for keeping their own private references 
> (you can limit it to just a few kilobytes per person, so you might as well 
> just consider it to be part of their "user information" thing along with 
> whatever other preferences they have).
> 
> Then, they call all share the objects, and there's never any confusion
> about tags - everybody has their own tags, and you add a few simple
> operations like "copy user xxx's tag to my tag-space, and start a new 
> branch from that".
> 
> There're really no downsides. The only thing you need to have is some nice
> tag-browser (and some simple permission model where developers can say
> "others can read my tag" or "this tag is visible only to me" - the object 
> store may be shared, but if nobody can see your pointers into the object 
> store, you effectively have a totally private branch - which might be 
> what some people want).
> 
> There's really never any reason to make tags global. Even in the case of
> the kernel, people don't want to see a tag like "v2.6.12". They want to
> see what _I_ tagged v2.6.12, so implicit in that whole thing is very much
> that they want to see _my_ tags. Again, it's a _browsing_ issue, not a
> "tags should be global" issue. They should be visible and easily 
> fetchable.
> 

OK, so let me retell what I think I hear you say:

- Store all the tags in the object store; they may conflict.
- Let each source user have a set of refs, and provide a method for the 
end user to select which refs to get.

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.

	-hpa