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

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 18 May 2007, Petr Baudis wrote:
> On Fri, May 18, 2007 at 02:00:07PM CEST, Jakub Narebski wrote:

>> 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.
> 
> Well, then it doesn't make any difference, no? You just renamed the
> problem but it stays the same - to ensure uniqueness even across
> repositories.
> 
> Ok, you can declare now that you will just think out a UUID for the
> subproject, but aside of not fitting well with the whole git philosophy,
> then you don't need the indirection again, just use the UUID as the tag
> name.
> 
> I have the feeling that I'm missing something basic in your proposal...

I was thinking about _automatic_ UUID, generated by git. For example it
could be sha1 of first subproject commit which appeared in supermodule.
It is easy to check if two UUID correspond to the same repository:
check if both objects are present, or perhaps that one is reachable from
the other, or that they have common parent. This kind of UUID is not
that different from (global) SHA1 of object.

So the idea is to have versioned, i.e. in-tree mapping from directory
names to repositories via some kind of identifier: Junio idea of using
URL of repository, with possibility of overriding it in repo config,
the idea of using tag name, and having URL for repo in tag contents,
and my idea of tag name of tag containing UUID. To find the URL you
would search all the repo-tags for UUID, or for existence of commit
with given sha1.

But I haven't thought this idea through, so it migh be utter rubbish.


The porcelain part of subproject / submodule support is not that
easy, to cover for moving subproject "mountpoint", project changing URL,
conflict of project names and different naming of the same project etc.
-- 
Jakub Narebski
Poland