Re: Question around git-shell usage in Everyday Git

Linus Torvalds [off-list ref] writes:

On Wed, 1 Feb 2006, Junio C Hamano wrote:

quoted

Do you mean to reuse single directory /home/gitu/ for user A, B, C,
and hang repositories /home/gitu/{X,Y,Z} for projects?  I'd
imagine things could be arranged that way.  User A and B but not
C may be in "projectX" group and /home/gitu/X is writable only
by projectX group members and such...

That would work from a _git_ angle, but I don't think that was what Alan 
was talking about, and it would failr horribly from a "ssh" perspective 
(because "ssh" will want $HOME/.ssh/authorized_keys etc).

Hmph.  I thought that was what Alan was talking about, after he
read about the shared repository configuration section that
mentions git-shell, which is about shared repository.

Project administrator or project secretary sets up the shared
repository for the project and member accounts on that machine,
and members just use that shared repository.  Not allowing
remote repository creation nor deletion over git-shell is a
slightly lesser issue in this context.

However, to be truly useful for this kind of hosting schenario, 
"git-shell" still needs to be extended to be able to at a minimum create 
(and delete) projects.

Hosting is a different story and I think branch/tag removal in
addition to repository creation, and deletion you listed above
are needed in that context.  Your "my projects are all under my
HOME directory, it is very convenient and things naturally work"
would apply for non-shared (i.e. something each person can call
"my") repositories, and would apply to hosting situation, of
course.

It probably also makes a lot of sense to be able to pre-populate a 
project, so that you don't have to do a remote "git push" to push a big 
project over the network, when another version of that project already 
exists at the hosting site.

Depends on what you mean by pre-populate, but that may just mean
to be able to manage objects/info/alternates remotely.
Capability to manage hook scripts may also be needed to a
certain degree if the repository side access control (e.g. who
can push into this branch) is done by hooks/pre-update, but in
either the hosting environment or a shared project setup, the
machine owner who is paranoid to install git-shell would want to
control what hooks can do very carefully.  The operator would
probably not allow updating of hooks at all, but install a BCP
hook by Carl Baldwin.  The users can only manage what is in the
info/allowed-{users,groups} file.

What this implies is extending what git-shell allows is a
concious policy decision and probably be quite different from
site to site until a set of BCP emerges.