Hi,

On Thu, 22 Dec 2005, Andreas Ericsson wrote:

quoted text
> Johannes Schindelin wrote:
> > Hi,
> > 
> > On Wed, 21 Dec 2005, Junio C Hamano wrote:
> > 
> > 
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > > 
> > > 
> > > > If you don't use git-shell, because the same machine is used for other
> > > > purposes, it makes sense to introduce
> > > > 
> > > > 	[core]
> > > > 		umask = 0002
> > > 
> > > I agree the setting should not be limited to git-shell, but I do
> > > not think setting "umask" from git configuration is the right
> > > way either.  For files and directories under $GIT_DIR, maybe
> > > imposing the policy git configuration file has is OK, but I
> > > think honoring the user's umask is the right thing for working
> > > tree files.
> > 
> > 
> > As we worked out in another thread, you should not have a working directory
> > when you write-share the repository.
> > 
> 
> Which thread was that? I see no particular problem with having a working
> directory in a write-shared repo. The same care has to be taken there as
> everywhere (pull before push), but that's nothing new.

It was the thread "How to set up a shared repository".

Okay, so there you are. You have a write-shared repository with the HEAD 
checked out. Somebody wants to push to that with different credentials 
than the user who checked out the files. Do you plainly deny updating the 
current HEAD?

If you do, then you better give the pushing user (pun intended) a way to 
update the checked out files. You can do this by (tadaah) setting the 
umask to 0002 also for working files.

Yes, we could find out exactly where writes happen inside GIT_DIR and plug 
in shared.umask which is only applied in these cases, but I am totally 
unconvinced that this is worth the hassle. In my cases, I am perfectly 
helped by a umask which is respected throughout git, and the patch is 
simple enough to be reviewed in 5 minutes.

Ciao,
Dscho

-
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