Dear diary, on Sat, Jul 02, 2005 at 11:42:51PM CEST, I got a letter where "H. Peter Anvin" <hpa@zytor.com> told me that... > Linus Torvalds wrote: > > > >Note that the fact that you use a common object store does not mean that > >everything should be common. \o/ Finally I have some hope that we don't end up with something braindead w.r.t. the tags... ;-) ..snip.. > OK, so let me retell what I think I hear you say: > > - Store all the tags in the object store; they may conflict. They may have the same "human-readable name", but they will have a different hash. > - 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. After all, this is the best way to distinguish it, isn't it? Just "tag name" without a name of the branch the tag concerns makes no sense - that's the point I'm trying to get along. JRH's v2.6.12 wouldn't make much sense to you if you use Linus' v2.6.12, since the object JRH's v2.6.12 references simply may not be in the branch you use. Yes, JRH could tag it somewhere in the common past, but that's kind of strange and is likely some private JRH's stuff. If Linus merged JRH, he will take his v2.6.12 if it makes sense in his branch - so the decision is then up to the one who merges, which makes some sense too. FYI, I'll teach Cogito about the refs/tags/<branch>/<tag> later today (and totally offtopic, it already has some trivial cg-push now). It will still fall back to refs/tags/<tag>. > This also means the refs cannot be uniquely rebuilt from the > object storage. Why should they be, after all. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ <Espy> be careful, some twit might quote you out of context.. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Jul 09 16:35:36 2005
This archive was generated by hypermail 2.1.8 : 2005-07-09 16:36:07 EST