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

From: Henri GEIST <geist.henri@laposte.net>
Date: Mar 10, 2014, 09:08 UTC
Message-ID: <1394442486.7891.45.camel@Naugrim>
In-Reply-To: <531A4FA3.3040007@web.de>

Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :

Show 91 quoted lines

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

The problem is having two gitdir for one worktree.
with the .git file in the worktree pointing sometime on one and sometime on
the other.

Show 7 quoted lines

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

Only lot of careful manual command by the user could keep them synchronize. But it is big wast of time. For no added value. It is quicker to make subsubmodule a regular clone without a separate gitdir then there is nothing needing a synchronization.

Show 21 quoted lines

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

I will not redundantly create a branch for each user on the server. When users clone the server it already create a special branch for them 'master' which track 'origin/master'. And if each user have its own branch on the server it will completely defeat the goal of the server "collaboration". And transform the git server in simple rsync server.

Show 9 quoted lines

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

If I use symbolic links it will just as gitlink enable to use the
same subsubmodule clone by more than one superproject but with two
major problems :
  - symbolic links do not work under Windows and some of my users do
    not even know something else could exist.
  - symbolic links will not store the SHA-1 of the subsubmodule.
    And a 'git status' in the repository containing the symbolic link
    will say nothing about subsubmodule state.

I think where we diverge is in the way we are looking gitlinks. Where you see a hierarchic tree, I see a web. And I use gitlinks just like multiplatform symbolic links storing the SHA-1 of there destination and pointing exclusively on git repositories.