Re: git-cvsserver doesn't respect core.sharedrepository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/14/07, Andy Parkins <andyparkins@xxxxxxxxx> wrote:
On Tuesday 2007, February 13, Johannes Schindelin wrote:

> Ummm. What I tried to say is that this is intended behaviour, not bad
> behaviour. The file does not have to have write permissions for the
> group. The _directory_ has to have them.

It's not just write permissions.  The default umask could also prevent
read access by the group - the new ref needs to be readable by the
group.

I agree. cvsserver depends on the user's umask just like an oldstyle
cvs server. This is probably wrong, and you are right - we should
respect core.sharedrepository.

The recent change to use git-update-ref should have fixed part of the
problem. The other part of the problem is the handling of the sqlite
files. All the other operations that leave permanent files in the repo
are using git plumbing so we are safe.

To fix the sqlite files handling, the fix is to change the umask early
on if core.sharedrepository is true.

cheers,


martin
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]