On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote:
> Hi Joakim,
> 
> On 2015-09-22 22:58, Joakim Tjernlund wrote:
> > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote:
> > > 
> > > The reason should be easy to understand: Git's concept is based on the 
> > > idea that you have full control
> > > over
> > > your repository. Other repositories you might only have read access.
> > 
> > Yes and some repos I only have partial write access to(config, hooks
> > etc. might be readonly)
> 
> The partial write access idea is definitely not part of the original idea of 
> Git, and your use case is
> actually the first I heard of.

Ouch, that cannot be so?? The first thing one would do for some level of 
accident protection 
would be to just change privs on a few selected files/dirs. 

> 
> The original idea was really that you either own your repository, or you do 
> not. And that includes the
> repositories that can be accessed publicly: you own them or you don't.
> 
> Now, I know that in particular in some corporate setups, there needs to be a 
> permission system in place that
> disallows certain users from doing certain things (such as editing the 
> config).

Exactly! This is what we are doing.

> 
> The Git solution is to set up a server, usually with SSH, and allow users to 
> push and fetch from the
> repositories, but nothing else (i.e. no shell access), then set up hooks to 
> implement the permission system.

But this is too big of an ax just to get any protection at all. Dedicating a 
server just for this
is very costly, both the physical/virtual server and to maintain it. 

> 
> This is much less error prone than partially locking down a repository on 
> some network drive because the
> file system structure simply does not reflect the permission structure. That 
> is where all your troubles come
> from.

Sure, but here is room for improvement.

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

Reply via email to