Re: [PATCH] submodule : Add --no-separate-git-dir option to add and update command.

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 06.03.2014 21:15, schrieb Henri GEIST:
> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :
>> Am 06.03.2014 02:25, schrieb Henri GEIST:
>>> Le mercredi 05 mars 2014 à 19:13 +0100, Jens Lehmann a écrit :
>>>> Am 03.03.2014 21:34, schrieb Henri GEIST:
>>>>>   - I use an other patch which I plane to send later which enable multiple
>>>>>     level of superproject to add a gitlink to the same submodule.
>>>>>     And in this case the superproject containing the separate gitdir will be
>>>>>     arbitrary and depend on the processing order of the
>>>>>     'git submodule update --recursive' command.
>>>>
>>>> I don't understand that. How is that different from using different
>>>> names (and thus different separate gitdirs) for that duplicated
>>>> submodule? After all, the .git directory is just moved somewhere
>>>> else in the superproject's work tree, and as the name defaults to
>>>> the path of the submodule ...
>>>
>>> I think I should give an example.
>>> If I have a hierarchy like this :
>>>
>>> superproject/submodule/subsubmodule
>>>
>>> What I often do is:
>>>
>>> superproject --> submodule --> subsubmodule
>>>              |                 ^
>>>              '-----------------'
>>>
>>> Where '-->' is a gitlink.
>>>
>>>
>>> That mean .gitmodules and index of the superproject contain both submodule and
>>> submodule/subsubmodule.
>>
>> Wow, that shouldn't even work (as everything inside "submodule"
>> shouldn't be part of the superproject but must be contained in
>> the submodule itself). Do the "git submodule" script and other
>> git commands like "git status" work for you in such setups?
> 
> As I stated above it is the purpose of the other patch that I have not already send
> to implement this behavior. And that is why it work.

Ok.

> Everything including 'git submodule' and 'git status' work perfectly.
> The intent of this patch is only to permit this for gitlinks. Not for regular files.

But I still believe that this shouldn't be permitted at all,
no matter if files or submodules are concerned. The pitfalls
files face in such a scenario are pretty much the same for
submodules too.

>>> and also mean (and that is the point) subsubmodule is a direct 'child' of both
>>> superproject and submodule.
>>
>> Which I think should not be possible. If that works with current
>> Git I suspect we have a bug to fix ... or does your other patch
>> make this work?
> 
> You have no bug on this point without my modification this is not possible.

Glad to hear that.

>>> In this case where should the separate gitdir of subsubmodule be placed ?
>>>   - In superproject/modules/submodule/subsubmodule ?
>>>   - In superproject/submodule/modules/subsubmodule ?
>>>   - Depending on the 'git submodule update' command order ?
>>>   - Or both ?
>>
>> It should be placed in .git/modules/submodule/modules/subsubmodule
>> of the superproject (assuming the subsubmodule is part of the first
>> level submodule). But in your example that would live in
>> .git/modules/submodule/subsubmodule (but as mentioned above, I do
>> not consider this a valid setup because then two repositories would
>> be responsible for the data inside subsubmodule, which will lead to
>> lots of trouble).
> 
> That is why a had proposed an option '--no-separate-git-dir'
> for 'git submodule <add|update>' then no repository is responsible for the data
> in subsubmodule except subsubmodule itself.

As I mentioned in my other email, it doesn't matter at all for
the setup you're describing if the git directory lives under
.git/modules of the superproject or in a .git directory in the
submodule. The problem you're creating with your future patch
is related to the work tree, not the GIT_DIR: "subsubmodule"
could also be added to and tracked by "submodule" (as that is
completely unaware of "subsubmodule" already being tracked by
the superproject). Then you would end up in real trouble, as
"superproject" and "submodule" could have differing SHA-1s
recorded for subsubmodule. Don't go there, for just the same
reasons we do not allow that for files.

What is the use case you are trying to solve and why can that
not be handled by adding "subsubmodule" inside "submodule"?