On Sat, 2 Dec 2006, Torgil Svensson wrote: > > Here's an real-world example that doesn't contradict: And I'll add the note that people who do things like submodules aren't generally even _used_ to them being "seamless", and most of the time probably don't even want complete seamlessness. As the example that Torgil points to shows, people are quite used to actually even naming the submodules separately, and things like having the "default" set of submodules not equal the "complete" set. In other words, I don't think people expect or want something hugely more complicated than the CVS/modules kind of file. What people _do_ want (and that CVS in general is horribly bad at, and this is not a module-specific issue) is to have the _versioning_ work well. When you check out a specific version of a module, you want any _linked_ modules to follow along too. This is the same reason why CVS users use tags a lot: because even _within_ a single project (no modules, no nothing), it's often hard to re-create the exact state of a version any other way. So you tag every single file and do insane things like that, because CVS just isn't very good at guaranteeing consistency across the whole project. The exact same thing is true about subprojects. I don't think that people who have used CVS subprojects a lot really mind the CVS/modules file itself (but hey, maybe I'm wrong - I've seen _other_ people maintain modules in CVS, but I've never done it myself), but they do mind the fact that it's hard as hell to do something as simple as "get all modules back to version X" without lots and lots of careful crud (ie tagging every singl emodule, things like that). Now, I'm not exactly sure who wants to use git modules, so this is the time to ask: did you hate the CVS/modules file? Or was it something you set up once, and then basically forgot about? People clearly use the ability to mark certain modules as depending on each other, and aliases to say "if you ask for this module, you actually get a set of _these_ modules". _I_ suspect that that isn't the problem people had, and isn't what they have any problems with. What CVS didn't do very well (or at all, afaik) is to say "I want supermodule version XYZ", and then got all the submodules automatically to that (reliable) state. And THAT is something I think is really important for submodules, and it's why I think the most important part isn't actually all the veneer to make "git clone" and "git pull" work (which is really about the CVS/modules kind of wrapper parsing), but actually about the supermodule "tree" object pointing to a very specific version, so that you get the exact same "atomic snapshotting" of multiple trees that you get within a single git tree. In other words, I _suspect_ that that is really what module users are all about. They want the ability to specify an arbitrary collection of these atomic snapshots (for releases etc), and just want a way to copy and move those things around, and are less interested in making everything else very seamless (because most people are happy to do the actual _development_ entirely within the submodules, so the "development" part is actually not that important for the supermodule, the supermodule is mostly for aggregation and snapshots, and tying different versions of different submodules together). So that's where I come from. And maybe I'm totally wrong. I'd like to hear what people who actually _use_ submodules think. 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