Re: Tags
From: Petr Baudis <hidden>
Date: 2016-06-15 22:42:01
Dear diary, on Fri, Jul 01, 2005 at 11:52:51PM CEST, I got a letter where "H. Peter Anvin" [off-list ref] told me that...
You're missing the whole point of the discussion. Right now the only thing that makes a global object store impossible is the potential for a tag conflict, either intentional or accidental.
Ok, I was arguing about something a bit different here, sorry. The point of refs/tags/ should be to just indicate tags which we have in the current head (remember that this structure comes from the times before Dave, when the repository:"master branch" mapping was 1:1), since that are usually the only objects you have in _your_ repository. What's the point of having tag linux-1.0.4-ac128 when you don't have the linux-1.0.4-ac branch whatsoever? The distinction of "public" vs "private" tags here is really only that the "public" tags should be propagated to your head when you merge the remote head. This way, each head will have its own set of tags, and it will be only tags which actually reference objects relevant to the head. Now that we can have many branches in a repository, each with its own set of tags, we should probably extend the tags hierarchy to refs/tags/<head>/<tagname>. And see, you can actually have that in the global object store, as long as the head names are unique. But heads don't propagate in any way so that's a purely administrative issue on the global store side. BTW, I don't think many (most?) heads named "master" are big issue. That's how the head is called locally, and noone says that's how the head should be known at the other side too. It's fine to have a head called "master" in your repository and when pushing to the global object store call it "pasky/linux-l33t" over there. (If you are using Cogito, you can add that branch using a URL proto://global/obj/store#pasky/linux-l33t.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ <Espy> be careful, some twit might quote you out of context..