Linus Torvalds wrote:
On Mon, 4 Dec 2006, Torgil Svensson wrote:
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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html