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

[Henri GEIST <geist.henri@laposte.net>]

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

May be you have a good argument for this belief ?

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.
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) ?"

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

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

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

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. And I need superproject to add also
submodule/subsubmodule.