Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit : > 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 ' 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. > > 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. > >> 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. > > > 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.