Re: [RFC] Submodules in GIT

Linus Torvalds wrote:

On Mon, 4 Dec 2006, Torgil Svensson wrote:

quoted

Okay, missed that part.  I wasn't familiar with contents of the CVS
modules files and misinterpreted your suggestion.

MODULE [OPTIONS] [&OTHERMODULE...] [DIR] [FILES]

So all this is UI only and the "normal" operations on the supermodule
will just ignore what's behind the commit-links?

Right. That's how CVS modules work (although in the case of CVS modules, 
the "dir" thing is obviously there in the "modules" file, so it's not 
_purely_ UI in CVS - this would likely be different in a git 
implementation, because the "tree" object ends up telling not just the 
exact version, but the location too).

So my suggestion basically boils down to:

 - "fetch" and "clone" etc will just look at the "modules" file, and 
   recursively fetch/clone whatever the module files talks about. This is 
   the "thin veneer to make it _look_ like git actually understands 
   submodules" part. It woudln't really - they're very much tacked on.

 - the tree entries are what makes the "once you have all the submodule 
   objects, this is how you can do 'diff' and 'checkout' on them, and this 
   is what tells you the exact version that goes along with a particular 
   supermodule version".

In other words, the simple and stupid way to do this is to just consider 
these two things two totally independent issues, and have different 
mechanisms for telling different operations what to do.

Is it "pretty"? No. The whole sub-module thing wouldn't be a tightly 
integrated low-level thing, it would very much be all about tracking 
multiple _separate_ git repositories, and just make them work well 
together. They'd very much still be separate, with just some simple 
infrastructure glue to make them look somewhat integrated.

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.

Indeed. With the "tight" integration option we'd also have to have the 
mechanism to rewrite the tree-entries with the location where the 
submodule is located in the working tree. This might be needed anyways, 
but it sure as hell seems a lot easier to just tack that part on when 
doing a checkout and actually creating all the files.

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