On Tue, Oct 14, 2014 at 09:51:22PM +0200, Jens Lehmann wrote: > Am 14.10.2014 um 20:34 schrieb Max Kirillov: >> But here are a lot of nuances. For example, it makes >> sense to have a superproject checkout without submodules >> being initialized (so that they don't waste space and >> machine time for working tree, which often is more than >> repository data). > > Hmm, I'm not sure if this is a problem. If the > GIT_COMMON_DIR does have the submodule repo but it isn't > initialized locally, we shouldn't have a problem (except > for wasting some disk space if not a single checkout-to > superproject initializes this submodule). If initially a repository is clone without submodules, it will not have anything in the GIT_COMMON_DIR. > And if GIT_COMMON_DIR does not have the submodule repo > yet, wouldn't it be cloned the moment we init the > submodule in the checkout-to? Or would that need extra > functionality? I cannot say I like this. Network operations should be caused only by clone and submodules. I think the logic can be simple: it a submodule is not checked-out in the repository "checkout --to" is called from, then it is not checked-out to the new one also. If it is, then checkout calls itself recursively in the submodule and works like being run in standalone repository. >> Then, a checkout copy of a submodule can be standalone >> (for example, git and git-html-docs are submodules of >> msysgit). Or, it can even belong to some other >> superproject. And in that cases they still should be able >> to be linked. > > Maybe such configurations would have to be handled > manually to achieve maximum savings. At least I could live > with that. To make manual handling of the cases, and to skip checking-out a module. I would think about the following interface: $ git checkout --to ... - does not checkout submodules, creates empty directory. $ git checkout --recursive --to ... - if a submodule is checked-out in source repository, recursed there and run "checkout --recursive" again. If a submodule is not checked-out, does not checkout it, creates an empty directory. By the way, I have found your branch recursive_submodule_checkout. Would you like to revive it? Then it can be done with the same option. > Hmm, so I tend towards adding GIT_COMMON_DIR to > local_repo_env until we figured out how to handle this. > Without that I fear bad things will happen, at least for a > superproject with multiple checkout-to work trees where > the same submodule is initialized more than once ... I learned about local_repo_env and agree it should include GIT_COMMON_DIR. Unless it is removed at all... -- 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