Re: [3/4] What's not in 1.5.2 (new topics)

[Jakub Narebski <jnareb@gmail.com>]

[Cc: Petr Baudis <pasky@suse.cz>, Josef Weidendorfer
<Josef.Weidendorfer@gmx.de>, "Michael S. Tsirkin" <mst@dev.mellanox.co.il>,
Junio C Hamano <junkio@cox.net>, Andy Parkins <andyparkins@gmail.com>,
Nicolas Pitre <nico@cam.org>, git@vger.kernel.org]

Petr Baudis wrote:
> On Fri, May 18, 2007 at 02:32:53AM CEST, Steven Grimm wrote:

>> For example -- and yes, this is partially a rehash of other people's 
>> ideas -- instead of mapping a subproject path directly to revision@URL, 
>> instead map it to revision@symbolic name. The symbolic name is then 
>> separately mapped to a URL, and it's that symbolic name that can be 
>> locally overridden. The mappings of symbolic names to URLs is 
>> unversioned; the mapping of subprojects to revision@symbolic is 
>> versioned. Local overrides happen at the symbolic->URL mapping.
>> 
>> So you'd have something like
>> 
>> version 1: kernel-src/ -> kernel24
>> version 2: kernel-src/ -> kernel26
>> unversioned:
>>    kernel24 -> git://whatever/2.4
>>    kernel26 -> git://whatever/2.6
>> 
>> And then locally, the override is:
>> 
>>    kernel24 -> git://myhost/2.4
> 
> Yes, this would be nice; in one of my first mails in this thread I
> devoted a non-trivially large writeup to this, then proceeded to remove
> it since this has a serious problem.
> 
> Actually, Git already has a nice mechanism to handle these unversionaed
> pointers - tags. Just make refs/tags/subproject/kernel24 containing the
> URL to fetch. It's even easily overridable locally (and not easily
> overridable remotely...).
> 
> The problem is ugly too, though - suddenly, you have created a SINGLE
> UNIVERSE-WIDE NAMESPACE INSIDE A DISTRIBUTED VCS. And that's not going
> to work well. I think I don't have to elaborate too much - the
> aforementioned FreeBSD people will have different ideas about kernels
> than you, _you_ will have different idea about kernels in few tens of
> years than now, then if you need to merge or probably even fetch, you
> will get into big trouble.
> 
> Notice that we don't have any such namespace right now (except the
> D(SHA1) namespace, which is however possible only because it's so huge
> _and_ the names are assigned automagically in a way that virtually
> guarantees uniqueness across the whole universe) - tags come closest,
> but there is nothing that fundamentally breaks when a clash happens
> inside the namespace - it's just UI thing. But subproject names are
> etched to the history - once you name it, you just can't get rid of it
> forever.

There is a bit ugly solution for this: instead of using symbolic name
in versioned .gitmodules for a subproject (for a repo), use subproject
identifier (inode), and put it in the tag object (or config) together with
the URL.  Git would then search all the subproject / submodule info for
a given inode.  You could have more than one inode / identifier name for
a subproject repo; this would avoid the "independently created" issue
with using inodes / file-ids in distributed SCM.  One would have to
ensure however that different subprojects get assigned different inodes.

This is yet another level of indirection, and needs searching all the
subprojects info; but I don't think that there would be that many
subprojects used.


Besides we make use of one such global namespace: version tags (although
they _could_ have different names, e.g. v0.6.0 and gitgui-0.6.0).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git