From: Mark Hills <mark@pogo.org.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: sharedRepository derived from file permissions
Date: Wed, 17 Oct 2012 00:20:56 +0100 (BST) [thread overview]
Message-ID: <1210170009180.2113@vega> (raw)
In-Reply-To: <7vhaq4nc7g.fsf@alter.siamese.dyndns.org>
On Mon, 8 Oct 2012, Junio C Hamano wrote:
> Mark Hills <mark@pogo.org.uk> writes:
>
> > We make extensive use of unix permissions and core.sharedRepository --
> > multiple developers push to the same repo.
> >
> > I have often wondered why core.sharedRepository is needed at all as a
> > separate configuration?
> >
> > It looks like it might be easier (and less confusing to users) to derive
> > this attribute from the top-level .git directory?
>
> Hrm, clever ;-)
>
> > Is there a reason why Git doesn't just follow (and echo) the top-level
> > permissions?
>
> Other than "we did not trust that all the end users are capable of
> doing the right 'chmod 2775 .git && chgrp project .git", with a
> little bit of "we didn't think of that when we wrote the system", I
> do not recall any.
Thanks. If I understand, you mean it might be worth a try to implement
this. For us it would certainly simplify, and reduce mistakes/confusion.
I've yet to look into the code, but I will try and do this. If you have
any hints or recommendations where to begin then that'd be good.
I think I did peek some years ago to find out that it was non-trivial, and
then came up with the script!
I wonder if there are any users who are granting permission to specific
branchs or tags or tag directories. I'm not sure if this is really a valid
use case, but there might need to be a way to ignore the top-level
attributes too for some special cases?
Thanks
--
Mark
next prev parent reply other threads:[~2012-10-17 7:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-08 9:07 sharedRepository derived from file permissions Mark Hills
2012-10-08 16:46 ` Junio C Hamano
2012-10-16 23:20 ` Mark Hills [this message]
2012-10-17 7:46 ` Junio C Hamano
2012-10-17 12:25 ` Mark Hills
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1210170009180.2113@vega \
--to=mark@pogo.org.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.