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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html