On Thu, 12 Apr 2007, Sam Vilain wrote: > > Also, in the Perl 5 Perforce conversion there are a number of > "submodules" (ie, bundled modules with their own history) that move > around a lot. In some tree representations used during the conversion > process they might even appear twice in a given tree with differing > versions. That should actually be something that is fairly natural to handle with the current git submodule design - there's absolutely no problem with having the same subproject showing up in multiple different places in the tree (and each place obviously will have its own commit). However, it causes some questions at two points: - What do you do in the ".gitmodules" file, where you describe the submodule setup? This is not so much a _problem_ as a "how do you want to handle it" issue. Would people want such a module to show up as "one module" that is just visible in the tree in multiple places? Or do people prefer to think of of it as completely separate modules that just happen to have the same base repository? I don't think it's clear that one or the other is the "right way" to see things, and I don't think git really should care. I suspect it's more likely to be a detail that some importer script just has to resolve one way or the other. The core git infrastructure needs to be able to have one module show up in multiple places over time anyway, so I don't think there is any real reason not to allow the same module to show up in multiple places even within one single commit.. (Ie it's really mostly about the .gitmodules file *syntax* - but if we use the config file syntax, it's actually very natural to allow multiple entries for the module directory name) At the same time, there are reasons why you might want to consider them separate modules too - maybe you want to *descibe* them separately, and maybe one of the copies is used for "legacy support", and you might be in a situation where you want to check out only one of the copies and not the other (and thus describing them as two *different* modules rather than two versions of the *same* module actually makes sense!). So I think this is something where we are technically neutral, but where we may have non-technical issues to choose one representation over another (and those issues may have more to do with the *importer* than with any git issues - if importing from Perforce, it probably makes most sense to make the import behave as much as possible the way Perforce did in that case, and I have *no* idea what that is ;) - After a conversion is done, and you're no longer talking about a historical archive, but a "going forward" concern, exactly how automatic is subproject movement going to be, and what are downstream developers that pull these things supposed to do when a subproject that they have checked out is moved? This is mostly a UI issue. I suspect that the initial answer is: "you may have to un-check-out a subproject, then pull the superproject, and then re-check-it-out to get it in the new location". Simply because it's going to be a lot easier to do than actually having "git pull" notice when subprojects move. IOW, that is more of a "just how nice do we want to be to people", and I _think_ the answer is: "as nice as possible, but some things are more important than others, and some things might take longer before they are really pleasant to do" ;) Hmm? 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