Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Thomas Rast wrote: >> Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html