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

[Max Kirillov <max@max630.net>]

On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote:
> Am 15.10.2014 um 00:15 schrieb Max Kirillov:
>> 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.
> 
> But when I later decide to populate the submodule in a
> "checkout --to" work tree, should it automagically also
> use the central storage, creating the modules/<name>
> directory there if it doesn't exist yet? I think that'd
> make sense to avoid having the work tree layout depend
> on the order commands were ran in. And imagine new
> submodules, they should not be handled differently from
> those already present.

Like place the common directory to
$MAIN_REPO/.git/modules/$SUB/ and worktree-specific part to
$MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB, rather
than placing all into the socond one? It would make sense to
make, but then it would be imposible to checkout a diferent
repository into the same submodule in different superproject
checkouts. However stupid is sounds, there could be cases
if, for example, at some moment submodule is being replaced
by another one, and older worktrees should work with older
submodule, while newer uses the newer submodule.

Maybe, there could be some options to tell the command which
populates submodules (which commands that are? "submodule update"
and other submodule subcommands? or there is something
else?) to use the curent checkout space or the main one. But
I would still leave it depend on what user explicitly calls
and where the initial submodule update is executed.

Also, could you clarify the usage of the /modules/
directory. I did not notice it to affect anything after the
submofule is placed there. Submodule operations use the
submodule repositories directly (through the git link, which
can point anywhere), or in .gitmodules file, or maybe in
.git/config. So there is actually no need to have that
gitdir there. Is it correct?

-- 
Max