Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 23, 2015, 22:48 UTC
Message-ID: <815b23cb50fa299d5a70b99f6ff04225@dscho.org>
In-Reply-To: <1443040900.29498.119.camel@transmode.se>

Hi Joakim,

On 2015-09-23 22:41, Joakim Tjernlund wrote:

Show 16 quoted lines

> On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote:
>>
>> 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??

Yes, it can be so. In fat, it is so.

Please note that I *did* encounter valid scenarios where some operations might not be desirable (and therefore need to be prevented).

One such scenario (maybe even the first one) was to prevent non-fast-forward pushes. But you will certainly agree that this cannot be prevented by mere file system permission: they are not fine-grained enough. So we introduced a config option -- because in contrast to file system permissions, Git *does* have the means to enforce that rule.

So it all comes back to the point I made earlier, and that I really would like you to understand: Git's concepts do not align well with file system permissions. Not well at all, in fact.

So the method of choice is indeed what you called that "big axe" which is not such a big axe after all. You just need to set up an SSH server and define very clearly in the hooks what you consider permissible. Yep, that's a bit of work, but it is less work than would be required of Git to bend it so the same could be done via file system permissions. And stay that way.

Now, it might be possible for some operations, to *make* Git align with that permission system. But that sounds more and more like the desired changes would require Git developers to put in a lot of work in favor of others being able to avoid work, just for the sake of keeping with an idea that has been demonstrated to be flawed. If you are looking for fans of that idea, count me out ;-) Of course, if you are willing to put in the work to make it possible to restrict certain Git operations simply by using `chmod`, and to pay attention that it stays that way, go right ahead and submit a patch series to that end... Junio already indicated that he would not be flatly opposed to accept such changes ;-)

Ciao, Johannes