Re: permissions

[William Pursell <bill.pursell@gmail.com>]

Alex Riesen wrote:
> 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