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