On Oct 23 23:04, Johannes Schindelin wrote: > On Tue, 18 Oct 2022, Corinna Vinschen wrote: > [...] > > That means, the results from the "env" method is equivalent to the > > "windows" method, just after checking $HOME. That's a bit of a downer. > > > > Assuming the "env" method would *only* check for $HOME, the user would > > have the same result by simply setting nsswitch.conf accordingly: > > > > home: env windows > > Except when the domain controller is (temporarily) unreachable, e.g. when > sitting in a train with poor or no internet connection. Then that latter > approach would have the "benefit" of having to wait 10-15 seconds before > the network call says "nope". > > This particular issue has hit enough Git for Windows users that I found > myself being forced to implement these patches and run with them for the > past seven years. > > Given the scenario of an unreachable domain controller, I hope you agree > that the `env` support added in the proposed patches _has_ merit.
Yes, I don't doubt an `env' method checking for $HOME even a bit. I'm just not sure as far as HOMEDRIVE/HOMEPATH/USERPROFILE are concerned. Those vars should be left alone, but we can't control that, so reading them from genuine sources is preferred. Sure, the downside in terms of the LDAP server is clear to me So I guess it's ok to allow the env method to read the values of those vars from the env. I would just feel better if we urge the user to set $HOME and read that exclusively. Corinna
