Re: jn/config-ignore-inaccessible (Re: What's cooking in git.git (Apr 2013, #10; Mon, 29))

[Thomas Rast <trast@inf.ethz.ch>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Thomas Rast wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>
>>> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
>>>  - config: allow inaccessible configuration under $HOME
>>>
>>>  When $HOME is misconfigured to point at an unreadable directory, we
>>>  used to complain and die. This loosens the check.
>>>
>>>  I do not think we agreed that this is a good idea, though.
>>
>> As a data point: yesterday on IRC, two users complained that they each
>> had this problem.
>>
>>   http://colabti.org/irclogger/irclogger_log/git?date=2013-05-03#l3022
>>   http://colabti.org/irclogger/irclogger_log/git?date=2013-05-03#l3111
>
> I think the approach taken in the patch above is a good one.  If
> /etc/gitconfig contains important configuration, it is still not
> ignored, errors other than permissions reading ~/.gitconfig are
> still fatal, and permissions errors accessing ~/.gitconfig are no
> longer fatal because they are expected as something very common
> in normal setups.
>
> I haven't been able to convince myself there is a different, better
> behavior to be found.  Special-casing inaccessible $HOME while still
> forbidding inaccessible $HOME/.config/git and $HOME/.gitconfig would
> seem strange.

What I found iffy about all of it is that the current failures happen
really late: they prevent the children spawned by the daemon for repo
handling from doing any useful work, while the daemon itself chugs along
nicely.

Wouldn't it be better to (attempt to) reload configs immediately after
switching to the new user/group, and then either warn or exit?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch