Re: [RFC] Submodules in GIT

[Jakub Narebski <jnareb@gmail.com>]

Robin Rosenberg wrote:

> lördag 02 december 2006 21:16 skrev Jakub Narebski:
>>
>> The problem with submodule as separate git repository is that if you
>> move submodule (subproject) somewhere else in the repository (or just
>> rename it), you have to update alternates file... and this happens not
>> only on move itself, but also on checkout and reset. But that can be
>> managed by having in alternates all possible places the submodule ends
>> into. I don't know if it is truly a problem.
> 
> A nasty problem with separate repositories for submodules is that when you 
> screw up and git complains about everything you try do do, you previously 
> could do rm -rf *; git reset --hard and retry whatever you were trying to do. 
> With separate repositories your submodules will be resting in /dev/null, 
> unless you're very, very careful. 

The solution to this concern could be having GIT_DIR for submodule
outside it's working area, for example somewhere in GIT_DIR of
the supermodule, and use either symlink or (to be coded) .gitlink
symbolic reference to GIT_DIR file. Disadvantage of that is that it
moves troubles with moving subproject (although there are no troubles
with simple subproject directory renaming) from alternates file to
GIT_DIR link representation in submodule.

As Linus said, there are advantages to having submodule repository use
separate object database (clone and other operation scaling, index size),
and I think they outweight the troubles with moving/renaming the directory
submodule resides in.

P.S. I think that the problem with bad performance of too large index
is similar to the problems filesystems have with directories with large
number of files; some filesystems solved this problem.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git