Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

[Junio C Hamano <gitster@pobox.com>]

Jens Lehmann <Jens.Lehmann@web.de> 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).