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

[Heiko Voigt <hvoigt@hvoigt.net>]

On Mon, Mar 10, 2014 at 10:08:06AM +0100, Henri GEIST wrote:
> Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :
> > Am 06.03.2014 23:20, schrieb Henri GEIST:
> > >> 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.

I do not think that is what Jens was suggesting. It does not matter in
which branch they work, they can directly use master if you like. What
he was suggesting is that they create their repository structure like
this:

git clone git@somewhere.net:superproject.git
cd superproject/submodule
git clone git@somehwere.net:subsubmodule.git
cd subsubmodule
... work, commit, work, commit ...

The same applies for the superproject. Now only someone with access to
the submodule has to update the registered sha1 once the work is pushed
to 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?
> 
> 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.

Here you are also missing something. What Jens was suggesting was that
you move your subsubmodule directly underneath the superproject and from
the old location you create a link to the new location for a quick
transition. But you can also change all paths in your project to point
to the new location. But in the new location you will have subsubmodule
registered as a submodule only that it is now directly linked (as
submodule) from the superproject instead of the submodule.

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

Well but the problem with a web is that it will introduce a lot of
problems that need to be solved. Some repository has to have the
authority about a file (or link). If you have a file in multiple
repositories overlayed how do you know who is in charge and when?

There is a reason why it is designed like this: simplicity. I currently
do not see how your web idea can be simple without introducing a lot of
user interface questions.

Cheers Heiko