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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html