Hi kusma, On Wed, 4 Jun 2014, Erik Faye-Lund wrote:
> On Wed, Jun 4, 2014 at 5:14 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > > > On Wed, 4 Jun 2014, Erik Faye-Lund wrote: > > > >> On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen <pclo...@gmail.com> wrote: > >> > On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal <ka...@ucw.cz> wrote: > >> >> @@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...) > >> >> void home_config_paths(char **global, char **xdg, char *file) > >> >> { > >> >> char *xdg_home = getenv("XDG_CONFIG_HOME"); > >> >> - char *home = getenv("HOME"); > >> >> + const char *home = get_home_directory(); > >> >> char *to_free = NULL; > >> >> > >> >> if (!home) { > >> > > >> > Just checking. Instead of replace the call sites, can we check and > >> > setenv("HOME") if it's missing instead? MinGW port already replaces > >> > main(). Extra initialization should not be a problem. I feel > >> > "getenv("HOME")" a tiny bit more familiar than > >> > get_home_directory(), but that's really weak argument as the number > >> > of call sites has not increased in 4 years. > >> > >> Yeah. But we already set %HOME% to %HOMEDRIVE%%HOMEPATH% in > >> /etc/profile, git-cmd.bat, gitk.cmd *and* git-wrapper... Do we really > >> need one more place? > >> > >> It seems some of these could be dropped... > > > > No. Git is not always called through Bash or the git-wrapper, > > unfortunately. > > I'm aware of that. But you said in a previous e-mail that e.g putty got > confused when we set HOME. How is this a problem for git.exe, but not > when we set it in the shell? The problem arises whenever git.exe calls subprocesses. You can pollute the environment by setting HOME, I do not recall the details, but I remember that we had to be very careful *not* to do that, hence the patch. Sorry, has been a long time. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html