Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > But I can't see how that can work by just sharing the modules directory > tree, as that contains work tree related files - e.g. the index - for > each submodule. AFAICS sharing them between work trees will work only > if the content of the modules directory is partly present in GIT_DIR - > for work tree related files - and only the common stuff is taken from > GIT_COMMON_DIR (Or did I just miss the magic that already does that?). The first time I saw the patch 3/4 in this series, my reaction was "Huh, why should the repository data and branch tips be separated out into multiple independent copies for the same module? Do we force users to synchronise between these copies? It does not make any sense at all." But that was until I read your message ;-) You are right that the index and HEAD are dependent to a particular working tree that is checked out. There may be other things that logically are per- working tree. And multiple-worktree _is_ about keeping the same repository and history data (i.e. object database, refs, rerere database, reflogs for refs/*) only once, while allowing multiple working trees attached to that single copy. So it appears to me that to create a checkout-to copy of a superproject with a submodule, a checkout-to copy of the superproject would have a submodule, which is a checkout-to copy of the submodule in the superproject. > And I didn't try to wrap my head around recursive submodules yet ... > > Until that problem is solved it looks wrong to pass GIT_COMMON_DIR into > submodule recursion, I believe GIT_COMMON_DIR should be added to the > local_repo_env array (and even if it is passed on later, we might have > to append "/modules/<submodule_name>" to make it point to the correct > location). -- 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