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

Jonathan Nieder [off-list ref] writes:

Thomas Rast wrote:

quoted

Junio C Hamano [off-list ref] writes:

quoted

quoted

* 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