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