On Fri, 1 Jun 2007, Lars Hjemli wrote: > On 6/1/07, Sven Verdoolaege <skimo@xxxxxxxxxx> wrote: > > > > Hmm.... I was thinking that the extra "path" level could be optional, > > i.e., if there is no path.$path.submodule, then the name of the > > submodule would simply be $path. > > Yeah, that should also work out. Time for a quick poll? Ack. I think the natural thing for a lot of cases is the trivial "module name == path" case, so having to have [path "kernel"] module = kernel for that case just sounds unnecessary. That said, I wonder if it wouldn't be more natural to do things the other way around, because quite often a "module" (under CVS conventions) is a *set* of directories, so with that in mind, it might be better to have the mapping be something like this: [module "infrastructure"] submodule = lib submodule = build [submodule "lib"] url = git://xyzzy/lib-1.2.3 [submodule "build"] url = git://xyzzy/build-0.61 and make the rule be: - submodules are named by their paths (ie "path == submodule") - a module is a set of such submodules/paths - if no "module" is defined, the default is to just use the path/submodule name IOW, in the above case, we have *three* modules: - module "infrastructure", that is the union of submodules/paths "lib" and "build" - module "lib" (== submodule/path "lib") - module "build" (== submodule/path "build") and when you do a git submodule checkout infrastructure it would be basically equivalent to git submodule checkout lib git submodule checkout build Hmm? That's how CVS users use modules (ie the "src" module may be much more than a single subdirectory) 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
