Re: [RFC] Submodules in GIT

If you need a common infrastructure to be able to work with the
submodule, then the submodule is not independent of of the supermodule.
I see a contradiction in your requirements.

Here's an real-world example that doesn't contradict:

http://amarok.kde.org/wiki/Installation_HowTo#From_Anonymous_SVN

"svn co -N svn://anonsvn.kde.org/home/kde/trunk/extragear/multimedia
cd multimedia
svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
svn up amarok

To compile the sources (from the multimedia directory):"

and there's probably very few people that want to clone the entire KDE
multimedia sub&super-module in this case.

//Torgil


On 12/2/06, sf [off-list ref] wrote:

Linus Torvalds wrote:

quoted

On Fri, 1 Dec 2006, sf wrote:

quoted

Linus Torvalds wrote:
...

quoted

In contrast, a submodule that we don't fetch is an all-or-nothing
situation: we simply don't have the data at all, and it's really a matter
of simply not recursing into that submodule at all - much more like not
checking out a particular part of the tree.

If you do not want to fetch all of the supermodule then do not fetch the
supermodule.

So why do you want to limit it? There's absolutely no cost to saying "I
want to see all the common shared infrastructure, but I'm actually only
interested in this one submodule that I work with".

If you need a common infrastructure to be able to work with the
submodule, then the submodule is not independent of of the supermodule.
I see a contradiction in your requirements.

quoted

Also, anybody who works on just the build infrastructure simply may not
care about all the submodules. The submodules may add up to hundreds of
gigs of stuff. Not everybody wants them. But you may still want to get the
common build infrastructure.

See above.

quoted

In other words, your "all or nothing" approach is
 (a) not friendly
and
 (b) has no real advantages anyway, since modules have to be independent
     enough that you _can_ split them off for other reasons anyway.

So forcing that "you have to take everything" mentality onyl has
negatives, and no positives. Why do it?

(There have been lots of use cases for shallow clones but for a long
time git did not support them).

If you can extend this partial fetch feature to the non-subproject case
I would agree with your reasoning. What makes the subprojects so special
in this regard. Do I have to turn a plain tree into a subproject to be
able to ignore it? Once you can restrict fetches to parts of the
contents you get the ability to restrict fetches to the "common
infrastructure" and selected submodules for free.

Regards

Stephan

-
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.html