Jon Jensen <jon@xxxxxxxxxxxx> writes:
> Below is a small patch to make git-init --shared change permissions
> not just of .git/refs/ but of the other directories too.
Those existing calls to adjust_shared_perm() are not about
changing permissions for existing directories, but are meant to
change the ones we _create_ under the user's umask() during the
initialization.
As you said, your change does not go far enough and you have to
tell the users to run "chmod" (and "chgrp") anyway. If we were
to update init-db, then it would need to do the recursive chmod
and chgrp itself.
However, the user need to do recursive chmod and chgrp to
correct earlier screwups and to adjust to the new reality anyway
(see below), and doing so using vanilla filesystem tools is
often easier. It might be better to train them early how to do
so, instead of making git-init a specialized command that knows
how to run chmod and chgrp in $GIT_DIR, as one of the major
strength of git comes from the fact that its implementation is
transparent. People who can read or write under $GIT_DIR can
access or build on the history --- it's just that simple.
Exposing users to the filesystem enhances that transparency.
Two reasons for correcting an initial screw-up, and two reasons
for adjusting the new reality are:
(A) making a non-shared repository to a shared one; you need
$ find .git -type d -print | xargs chmod g+rwxs
$ find .git -type f -print | xargs chmod g+rX
(B) the same as above but the repository is owned by your
personal group, not project; you further need
$ chgrp -R projectgroup .git
(C) an already shared project repository is transferred to a
new group; you need
$ chgrp -R newprojectgroup .git
(D) a shared repository is turned back to a private one; you
may need (if you are paranoid and do not want them to be
read):
$ find .git -type d -print | xargs chmod go=
$ find .git -type f -print | xargs chmod go=
or (if you only want to refuse writing)
$ find .git -type d -print | xargs chmod g-w
$ find .git -type f -print | xargs chmod g-w
Of course the above assumes that your umask is at most 077 (iow,
you did not forbid any access to yourself).
So I'd suggest us to do this in three steps:
Step #1. Documentation.
(1) How to transform a personal, non-shared project to a shared
one;
(2) How to transfer a shared project from one group to another;
(3) How to transform a shared project to a non-shared,
private one (two variants);
I think your documentation patch is a good start, but notice
the differences from the above (A)-(D).
Step #2. Teach "git-init --shared" to do (1),
Step #3. Discuss if we want to teach the "re-initialization"
mode of git-init to do (2) and (3) as well, and if so,
design and code it. We'd need new options to name the
desired group and such so it would involve an
interface change.
Personally, I suspect that we do not need to go any further than
Step #1 above, but people who like "magic" may disagree. Don't
take my suspicion as a rejection.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
