Re: permissions

From: William Pursell <bill.pursell@gmail.com>
Date: Jun 6, 2010, 09:36 UTC
Message-ID: <4C0B6C32.1090700@wpursell.net>
In-Reply-To: <AANLkTileRHwUuJpvKJbivRiM9Prn9wJ0zH6abExBgcq0@mail.gmail.com>

Alex Riesen wrote:

Show 8 quoted lines

> On Sat, Jun 5, 2010 at 20:23, William Pursell <bill.pursell@gmail.com> wrote:
>> fatal: Not a git repository (or any of the parent directories): .git
>>
>> That's just weird.  And if there is a git repository in a
>> directory above, there may be great confusion, weeping
>> and gnashing of teeth.
> 
> How about just this? (I assume cwd does hold current working directory).

<patch snipped>

The problem is permissions, not that it's "not a git repository". The error message should be "permission denied". The easy solution is to abort with "permission denied" whenever that is encountered, but the trouble with that is that it breaks the current work flow in which a broken dir (or one for which the user lacks priveleges) is bypassed and a valid object directory higher up in the filesystem tree is used.

Consider the case in which /etc/.git has mode 777 while /etc/sysconfig/.git has mode 700, each .git owned by root. (Granted, git is for recording development history and not so much for storing history of config files, but I believe this is a relevant use case.) /etc/sysconfig/foo is tracked by /etc/sysconfig/.git but not by /etc/.git. Regular user in /etc/sysconfig invokes 'git log foo' and is told: absolutely nothing. And when 'git status' is invoked, the message is that foo is untracked.

Now, if /etc/.git does track /etc/sysconfig/foo, then a regular user in /etc/sysconfig that invokes 'git log foo' sees the history tracked in /etc/.git, but root in /etc/sysconfig sees the history tracked by /etc/sysconfig/.git. This is confusing. The regular user in /etc/sysconfig should simply get 'permission denied' on all invocations of git.

A related question is: does anyone actually prefer (or rely on) the current model in which ../.git is used in the event that .git is borked or the user lacks permission? It seems to me that if an object directory is discovered which is borked or which is unreadable, git must abort with an error message indicating the relevant problem.

-- 
William Pursell