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

From: Jens Lehmann <[email-masked]>
Date: Mon, 03 Nov 2014 21:57:13 +0100

Am 03.11.2014 um 13:54 schrieb Duy Nguyen:
> Ping.. any idea how to go from here..

I didn't dig deep enough into the multiple worktrees topic to
know what "$MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB"
might mean, but a submodule whose repo lives under
.git/modules/$SUBMODULE_NAME should have its worktree in
$SUBMODULE_PATH of the superproject's worktree.

So if we share submodule repos, the sharable stuff should
live under $MAIN_REPO/.git/modules/$SUBMODULE_NAME/. But
everything that can't be put there should stay under the
.git/modules/$SUBMODULE_NAME directory in every worktree.
The same redirection mechanism the superproject uses to
redirect to $MAIN_REPO/.git should be used to redirect
the sharable stuff from .git/modules/$SUBMODULE_NAME to
$MAIN_REPO/.git/modules/$SUBMODULE_NAME/.

I believe this should be the default. Optionally we might
want to enable the user to put $MAIN_REPO/.git/modules
someplace else (outside the superprojects $MAIN_REPO) to
be able to reuse the object store of submodules that are
shared between different superprojects.

Does that make sense?

> On Mon, Oct 20, 2014 at 11:11 AM, Max Kirillov <[email-masked]> wrote:
>> On Sun, Oct 19, 2014 at 09:30:15PM +0200, Jens Lehmann wrote:
>>> Am 16.10.2014 um 22:54 schrieb Max Kirillov:
>>>> 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.
>>
>>> Yes, but I believe that the user must be careful to not
>>> reuse the same submodule name for a different repo anyways,
>>> no matter if shared or not. Currently you'll get a warning
>>> about that when trying to add a submodule whose name is
>>> already found in .git/modules to avoid such confusion.
>>
>> Yes, while trying to write tests for this case I discovered
>> that there are warnings and the recommended way is to use
>> different names for different repositories even if they are
>> pointing to the same path. Then always placing common
>> directory into the .git/modules/<module> could be a good
>> idea, and in very special cases users could manually create
>> repositories with custom placement.
>>
>>>> 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?
>>
>>> Nope. When submodules are cloned their git directory is
>>> placed under .git/modules/<submodule name>, the .git file
>>> in the work tree points there and the core.worktree setting
>>> points back from there to the work tree.
>>
>> I meant is the fact that gitdir is placed in modules, rather
>> than in any other place, is used anywhere. There are 2
>> places to put the gitdir of submodule in linked copy:
>> 1. $MAIN_REPO/.git/worktrees/$WORKTREE/modules/$SUB
>> 2. $MAIN_REPO/.git/modules/$SUB/worktrees/$SUB_WTNAME
>> First one is suggested by submodule way of placing gitdirs,
>> and the second one by worrktree way. There are reasons to
>> have the second one - garbage collection and check that 2
>> branch is not checked out twice. Are there resons to have
>> the 1st one? The one is to prevent use of different
>> repositories with the same name, anything else?
>>
>> --
>> Max
>
>
>