Re: [RFC] Submodules in GIT
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 3, 2006, 11:00 UTC
- Message-ID
- <ekuaka$6km$1@sea.gmane.org>
- In-Reply-To
- <200612030224.50592.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
Show 14 quoted lines
> 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