Hi, In git-cinnabar (the remote-helper that can talk to mercurial servers), I'm using a fast-import-derived helper to do a lot of the heavy lifting, because $REASONS. Anyways, while built (mostly) with the git build system, using libgit.a, etc. the helper doesn't live in the GIT_EXEC_PATH. That leads me to a very subtle problem: it doesn't necessarily find the system config that git uses. Because the system confit that git uses depends on how git was built, the result might not be the right thing. For one, a Linux distro git will likely have been built with prefix=/usr, which makes the system config be /etc/gitconfig, but someone building their own git will have a system config in etc/gitconfig relative to their git. The latter is more of nitpicking, because practically speaking, it doesn't matter much. Which is why I've been building with prefix=/usr (at least for the helper binaries that I ship pre-built ; locally built helpers actually don't get this treatment ; but that's also not much of a practical problem because it seems Linux distros don't ship a /etc/gitconfig anyways (at least Debian doesn't)). Anyways, the real problem comes on Windows, because git-for-windows does come with a system config that does make important tweaks, like setting http.sslcainfo to a path that actually exists. And without reading that system config, the helper doesn't find the cainfo file and fails to connect to HTTPS mercurial servers. Now, my question here is, what would you suggest I do to make my helper find the right config? I thought of a few options (it's worth noting the helper is invoked in a way that makes $GIT_EXEC_PATH set, which can help a little): - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the internal config from that. That's the barbarian option. - build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX code to use $GIT_EXEC_PATH if it's set, rather than the path the executable is in. That actually sounds reasonable enough that I'd send a patch for git itself. But that doesn't quite address the nitpick case where ETC_GITCONFIG could be either `/etc/gitconfig` or `etc/gitconfig` depending how git was compiled, and there's no way to know which is the right one. WDYT? Mike
