Jeff King <peff@xxxxxxxx> writes: >> If the access() failed due to ENOENT, the caller will get a negative >> return from this function and will treat it as "ok, it does not >> exist", with the original or the updated code. This new case is >> treated the same way by the existing callers, i.e. pretending as if >> there is _no_ file in that unreadable $HOME directory. > > Exactly. The explanation you are replying to was meant to illustrate how this is not "inaccessible is OK", but is "treat inaccessible as missing", by the way. >> That semantics sounds sane and safe to me. > > Thanks. I'll re-roll with a proper commit message and the fixups I > mentioned above. I think we should still do the documentation for > git-daemon. But it is no longer about "oops, we broke git-daemon", but > "you may want know that we do not set HOME in case you are doing > something tricky with config". I'll submit that with the re-roll, too. Well, at least to me, the documentation update was never about "oops, we broke it", but was about "be careful where the HOME you are using actually is" from the beginning of the suggestion. I was actually planning to apply it to maint-1.8.1 that predates the xdg stuff, and that is why the text only suggests to set HOME for the config. > Do you have an opinion on just dropping the environment variable > completely and behaving this way all the time? It would "just fix" the > cases people running into using su/sudo, too. With the tightening, people who used --user=daemon, expecting that they can later tweak the behaviour by touching ~daemon/.gitconfig, got an early warning that they need to set HOME themselves, but with any variant of the patch under discussion, as long as loosening is on by default, will no longer get that benefit. I am not yet convinced if that is a real "fix/cure". So, no, I have not even reached the point where I can form an opinion if this behaviour should be the default. -- 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