Re: [RFC] Submodules in GIT

Torgil Svensson wrote:

On 12/4/06, Linus Torvalds [off-list ref] wrote:

quoted

So yeah, it's a bit hacky, but for the reasons I've tried to outline, I
actually think that users _want_ hacky. Exactly because "deep 
integration"
ends up having so many _bad_ features, so it's better to have a thin and
simple layer that you can actually see past if you want to.

Thin and simple sounds very good. Let's try it with an example. Lets
say we have one apllication App1 and three librarys (Lib1, Lib2, Lib3)
with the following dependency-graph:

       App1
         /\
        /  \
  Lib1   Lib2
      \     /
       \   /
       Lib3 (don't really needed for this example but looks nice)

All components can be used individually and have their own upstream,
maintainer etc.

To compile App1 however, I need some files from both Lib1 and Lib2
specifying it's API. To satisfy these dependencies, It sounds
reasonable to link Lib2 and Lib3 submodules from App1. In your
concept, can I construct a modules file to fetch the API files and
their history without checking out the whole Lib1 and Lib2 source?

I think not. Then it wouldn't be a submodule anymore, but just some 
random sources from an upstream project. Not that it's an uncommon 
workflow or anything, but it's sort of akin to just importing the SHA1 
implementation (a few source-files with no real interest in the history 
of those source-files) from openssl into a different project rather than 
actually using the entire openssl lib (which would be nice to have as a 
submodule).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se