Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

quoted text
> And then somebody comes along and allows world access by chmod(0775) and 
> does not realize that *everybody* can delete packs, objects and what-nots 
> in GIT_DIR.

That somebody has to be somebody who owns .git directory not
just a group member, so that is not a serious objection either,
but you need to realize I was joking with 0777 -- a saner
default would obviously be 0775.  Otherwise you would not be
able to server it from gitweb safely -- http server is typically
not a group member.

quoted text
> Given the complexity we are talking about, and the needs which are not at 
> all that complicated, why not just go with core.umask until somebody 
> *needs* core.repositoryumask?

I am afraid that is going backwards.  Nobody *needs* core.umask
either, but we are still talking about this.  That is because
you wanted to make things easier for people, and I agree with
you that it would be nicer if we did not require people set
umask to sane values suitable for group work themselves, but
somehow we did that automatically for them.  The longer I think
about it, however, the more I feel this is a lost cause.

Earlier, I suggested git-shell one-liner, only because I thought
git-shell users (or administrators that support git-shell users)
may not have any way to set the umask to sane values themselves,
but I think that should also be doable by telling sshd what the
initial umask of the users should be.  And that was where this
umask discussion was started, but I think not touching umask at
all is the right direction.

Your core.umask would make sure the .git/objects/ directory
would be suitable for other members, but git is not the only
tool the people would use in the working tree.  To work well
with an editor that does not overwrite an existing file but does
creat/rename upon saving would require you to have a sane umask
if the user adopts your "shared working tree writable by all
members" workflow.  Running "make" in the working tree would
leave object files, worse yet in a temporary build directory
make created, with permission bits masked with your umask,
making it imposible to run "make clean" for other members.

Regardless of where and how people come from to work in the
working tree, they need to set umask appropriately anyway.

The only possible issue is one umask might not be sufficient,
but unfortunately you can have only one umask at a time.  The
example of "receiption branches" is not a shared repository for
me in the strict sense, but allows for you to push into.  I
cannot work with umask 022 in such a repository even if I wanted
to have files in the working tree honor tighter umask.  To deal
also with such cases, not mucking with umask but solving the
problem in a more direct way may make more sense -- namely we
should be able to say "such and such things under .git/ in this
repository must be ug+rw regardless of user's umask".

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html