Re: [Patch] Documentation: enhanced "git for CVS users" doc about shared repositories

From: Francesco Pretto <ceztkoml@gmail.com>
Date: Nov 6, 2007, 10:04 UTC
Message-ID: <47303C2E.2070103@gmail.com>
In-Reply-To: <7v8x5cmern.fsf@gitster.siamese.dyndns.org>

Junio C Hamano ha scritto:

Show 8 quoted lines

>>  ------------------------------------------------
>> -$ git clone foo.com:/pub/repo.git/ my-project
>> +$ git clone foo.com:/pub/scm/repo.git/ my-project
>>  $ cd my-project
>>  ------------------------------------------------
> 
> This part seems an unnecessary change.
>

Ironically, that's the same configuration of git.kernel.org. And I think is better to put immediately the project in a appropriate directory than to move it later.

> Don't assume the "admin privilege" part, as you do not have to.
>

Admin privilege SHALL be assumed, as this is a first time configuration, and the best we can do is to assume it's done on a default *nix installation. Moreover, it's what HEAD documentation is already doing when it suggests to give users ssh access.

Let's suppose the user "user1" create its own repository on a remote machine.
Now, he wants to selectively give write access on its repository to "user2".
There's 2 cases:
    1) "user2" have a local/ssh account on the machine. In this case, "user1" want
       to be sure only "user2" can write to the repository, so he can ask the admin
       to put "user1" and "user2" in the same group "projectx" or ask him to enable
       ACLs, still turned off in the majority of *nix systems.
    2) "user2" haven't a local/ssh account. Here:
	- a local/ssh account should be given to "user2", returning to 1)
        - mod_dav module has to be enabled for public http dirs of "user1"
        - git daemon has to be started and enabled to write on the repository.

The last 3 tasks all require admin privilege on default linux/bsd/macosx installations. However, a little distinction can be made. I'll see.

>
> needs, and there is no reason members of projects A and B should
> be in the same group 'git'

I agree!

> while having members of project C in
> group 'hg' only because A and B happen to use git.

I agree!

> belong to 'src' group, or (2) make three groups, one for each
> project.
>

It's exactly the point of:

+It's recommended, but not necessary, to create a specific group of commiters +for every project/repository. With root credentials launch: + +------------------------------------------------ +$ groupadd $group +------------------------------------------------

What you have understood here?

> Also with the "create new --shared repository for the project in
> a group's directory that has mode 2755" approach, I do not think
> there is any need to muck with umask either.
>

umask requirement is referred to previous version of git. It's still referred as actual in HEAD documentation. If it's ok for you, we could just cut away that reference.

Conclusion: i can try to amend my patch to be even more clearer. What i am saying
is that official documentation, commands manuals/syntaxes should be easy enough to the
first time user to set up git repositories without looking up the web for
"git tutorial"/"git installation"/"git umask 002", etc. (and consider that even an
expert sysadmin is a first time user, when he install and set up git the first time).
Or was better a "Documentation S**KS!" bug report?