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 <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.
> > 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.
signature.asc
Description: This is a digitally signed message part
