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

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

Am 06.03.2014 23:20, schrieb Henri GEIST:
> Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :
>> 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:
>>>> 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.
> 
> May be you have a good argument for this belief ?

Sure, I stated it further down:

>> 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.

> As for the difference between submodules and regular files
> the only difference is in the meaning.
> Technically directory are just a special kind of file.
> But there day to day use is drastically different of
> the use of files which are not directories.
> I am not against enabling it for files as well.
> I am just unable to imagine a case where it make sens.

It doesn't make sense for both files and submodules.

> A possible solution when someone try to do it is to issue a warning.
> "We are not able to see any good reason to do this are sure (y/n) ?"

No, the only possible solution I see is not to allow that at
all.

>>>>> 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.
> 
> In fact it mater.
> Because multiples checkout of superproject and submodules in versions
> where subsubmodule is present and not.
> subsubmodule could have been clone one time by submodule and one time
> by superproject.

And each would have a different .git directory. Where is the
problem with that? Size? Different refs?

> And then if they are cloned with --separate-gitdir subsubmodule can
> have two gitdirs in superproject/modules/submodule/subsubmodule and
> in superproject/submodule/modules/subsubmodule.
> Only one is active at a given time but they are two and not synchronized.

But the synchronization is done via the superproject, no?

>> What is the use case you are trying to solve and why can that
>> not be handled by adding "subsubmodule" inside "submodule"?
> 
> The problem is access rights.
> 
> Imagine you have 2 people Pierre and Paul.
> Each with different access write on the server.
> Pierre has full access on every things.
> Paul has full access on superproject and subsubmodule but no read/write
> access to submodule only execution on the directory.

Ok, I think I'm slowly beginning to understand your setup.

> I want all user to get every things they are allowed to have with the
> command 'git submodule update --init --recursive'.
> Then as Paul can not clone submodule he can not get subsubmodule
> recursively through it.

Sure, that's how it should work. Paul could only work on a branch
where "submodule" is an empty directory containing "subsubmodule",
as he doesn't have the rights to clone "submodule".

> And I need superproject to add also submodule/subsubmodule.

No. Never let the same file/directory be tracked by two git
repositories at the same time. Give Paul a branch to work on
where "submodule" is just an empty directory, and everything
will be fine. Or move "subsubmodule" outside of "submodule"
(and let a symbolic link point to the new location if the
path cannot be easily changed). Would that work for you?