{"thread":{"id":"50787","subject":"How to properly find git config in a libgit.a-using executable?","startedAt":"2019-03-20T10:27:30Z","lastAt":"2019-03-25T14:38:16Z","messageCount":6,"participants":["Mike Hommey","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"371974","messageId":"20190320101941.2xjsjx3zfnnp33a2@glandium.org","threadId":"50787","inReplyTo":null,"subject":"How to properly find git config in a libgit.a-using executable?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2019-03-20T10:19:41Z","receivedAt":"2019-03-20T10:27:30Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nIn git-cinnabar (the remote-helper that can talk to mercurial servers),\nI'm using a fast-import-derived helper to do a lot of the heavy lifting,\nbecause $REASONS. Anyways, while built (mostly) with the git build system,\nusing libgit.a, etc. the helper doesn't live in the GIT_EXEC_PATH. That\nleads me to a very subtle problem: it doesn't necessarily find the\nsystem config that git uses.\n\nBecause the system confit that git uses depends on how git was built,\nthe result might not be the right thing. For one, a Linux distro git\nwill likely have been built with prefix=/usr, which makes the system\nconfig be /etc/gitconfig, but someone building their own git will have\na system config in etc/gitconfig relative to their git.\n\nThe latter is more of nitpicking, because practically speaking, it\ndoesn't matter much. Which is why I've been building with prefix=/usr\n(at least for the helper binaries that I ship pre-built ; locally built\nhelpers actually don't get this treatment ; but that's also not much of\na practical problem because it seems Linux distros don't ship a\n/etc/gitconfig anyways (at least Debian doesn't)).\n\nAnyways, the real problem comes on Windows, because git-for-windows does\ncome with a system config that does make important tweaks, like setting\nhttp.sslcainfo to a path that actually exists. And without reading that\nsystem config, the helper doesn't find the cainfo file and fails to\nconnect to HTTPS mercurial servers.\n\nNow, my question here is, what would you suggest I do to make my helper\nfind the right config?\n\nI thought of a few options (it's worth noting the helper is invoked in a\nway that makes $GIT_EXEC_PATH set, which can help a little):\n- spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the\n  internal config from that. That's the barbarian option.\n- build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX\n  code to use $GIT_EXEC_PATH if it's set, rather than the path the\n  executable is in. That actually sounds reasonable enough that I'd send\n  a patch for git itself. But that doesn't quite address the nitpick case\n  where ETC_GITCONFIG could be either `/etc/gitconfig` or\n  `etc/gitconfig` depending how git was compiled, and there's no way to\n  know which is the right one.\n\nWDYT?\n\nMike\n"},{"id":"372208","messageId":"20190322073311.GA839@sigill.intra.peff.net","threadId":"50787","inReplyTo":"20190320101941.2xjsjx3zfnnp33a2@glandium.org","subject":"Re: How to properly find git config in a libgit.a-using executable?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-22T07:33:11Z","receivedAt":"2019-03-22T07:33:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:\n\n> I thought of a few options (it's worth noting the helper is invoked in a\n> way that makes $GIT_EXEC_PATH set, which can help a little):\n> - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the\n>   internal config from that. That's the barbarian option.\n> - build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX\n>   code to use $GIT_EXEC_PATH if it's set, rather than the path the\n>   executable is in. That actually sounds reasonable enough that I'd send\n>   a patch for git itself. But that doesn't quite address the nitpick case\n>   where ETC_GITCONFIG could be either `/etc/gitconfig` or\n>   `etc/gitconfig` depending how git was compiled, and there's no way to\n>   know which is the right one.\n\nI'm not entirely sure I understand the problem, but it sounds like you\nwant to know the baked-in ETC_GITCONFIG for a built version of git (that\nisn't necessarily the one that shares your build of libgit.a).\n\nThere's no direct way to have Git print that out. It would be reasonable\nto add one to rev-parse, I think.\n\nBarring that, here's a hack:\n\n  git config --system --show-origin --list -z |\n  perl -lne '/^file:(.*?)\\0/ and print $1 and exit 0'\n\nIf the file is empty, it won't print anything, of course. But then,\nyou'd know that it also has no config in it. :)\n\n-Peff\n"},{"id":"372240","messageId":"nycvar.QRO.7.76.6.1903221436590.41@tvgsbejvaqbjf.bet","threadId":"50787","inReplyTo":"20190322073311.GA839@sigill.intra.peff.net","subject":"Re: How to properly find git config in a libgit.a-using executable?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-22T13:39:43Z","receivedAt":"2019-03-22T13:40:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff & Mike,\n\nOn Fri, 22 Mar 2019, Jeff King wrote:\n\n> On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:\n>\n> > I thought of a few options (it's worth noting the helper is invoked in a\n> > way that makes $GIT_EXEC_PATH set, which can help a little):\n> > - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the\n> >   internal config from that. That's the barbarian option.\n> > - build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX\n> >   code to use $GIT_EXEC_PATH if it's set, rather than the path the\n> >   executable is in. That actually sounds reasonable enough that I'd send\n> >   a patch for git itself. But that doesn't quite address the nitpick case\n> >   where ETC_GITCONFIG could be either `/etc/gitconfig` or\n> >   `etc/gitconfig` depending how git was compiled, and there's no way to\n> >   know which is the right one.\n>\n> I'm not entirely sure I understand the problem, but it sounds like you\n> want to know the baked-in ETC_GITCONFIG for a built version of git (that\n> isn't necessarily the one that shares your build of libgit.a).\n>\n> There's no direct way to have Git print that out. It would be reasonable\n> to add one to rev-parse, I think.\n>\n> Barring that, here's a hack:\n>\n>   git config --system --show-origin --list -z |\n>   perl -lne '/^file:(.*?)\\0/ and print $1 and exit 0'\n>\n> If the file is empty, it won't print anything, of course. But then,\n> you'd know that it also has no config in it. :)\n\nHow about\n\n\tGIT_EDITOR=echo git config --system -e 2>/dev/null\n\nIt will error out if the directory does not exist, for some reason, e.g.\nwhen you installed Git in your home directory via `make install` from a\nfresh clone. So you'll have to cope with that contingency.\n\nCiao,\nDscho\n"},{"id":"372243","messageId":"20190322141925.olzzfjm5ytp2gwv7@glandium.org","threadId":"50787","inReplyTo":"nycvar.QRO.7.76.6.1903221436590.41@tvgsbejvaqbjf.bet","subject":"Re: How to properly find git config in a libgit.a-using executable?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2019-03-22T14:19:25Z","receivedAt":"2019-03-22T14:19:33Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:\n> Hi Peff & Mike,\n> \n> On Fri, 22 Mar 2019, Jeff King wrote:\n> \n> > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:\n> >\n> > > I thought of a few options (it's worth noting the helper is invoked in a\n> > > way that makes $GIT_EXEC_PATH set, which can help a little):\n> > > - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the\n> > >   internal config from that. That's the barbarian option.\n> > > - build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX\n> > >   code to use $GIT_EXEC_PATH if it's set, rather than the path the\n> > >   executable is in. That actually sounds reasonable enough that I'd send\n> > >   a patch for git itself. But that doesn't quite address the nitpick case\n> > >   where ETC_GITCONFIG could be either `/etc/gitconfig` or\n> > >   `etc/gitconfig` depending how git was compiled, and there's no way to\n> > >   know which is the right one.\n> >\n> > I'm not entirely sure I understand the problem, but it sounds like you\n> > want to know the baked-in ETC_GITCONFIG for a built version of git (that\n> > isn't necessarily the one that shares your build of libgit.a).\n> >\n> > There's no direct way to have Git print that out. It would be reasonable\n> > to add one to rev-parse, I think.\n> >\n> > Barring that, here's a hack:\n> >\n> >   git config --system --show-origin --list -z |\n> >   perl -lne '/^file:(.*?)\\0/ and print $1 and exit 0'\n> >\n> > If the file is empty, it won't print anything, of course. But then,\n> > you'd know that it also has no config in it. :)\n> \n> How about\n> \n> \tGIT_EDITOR=echo git config --system -e 2>/dev/null\n> \n> It will error out if the directory does not exist, for some reason, e.g.\n> when you installed Git in your home directory via `make install` from a\n> fresh clone. So you'll have to cope with that contingency.\n\nThank you both, I can probably work with this, although I might have to\nalter the git init sequence. I'm not sure my usecase needs git to cater\nfor it more generally, though. Who else uses libgit.a?\n\nMike\n"},{"id":"372297","messageId":"20190323063827.GA9227@sigill.intra.peff.net","threadId":"50787","inReplyTo":"nycvar.QRO.7.76.6.1903221436590.41@tvgsbejvaqbjf.bet","subject":"Re: How to properly find git config in a libgit.a-using executable?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-23T06:38:27Z","receivedAt":"2019-03-23T06:38:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:\n\n> How about\n> \n> \tGIT_EDITOR=echo git config --system -e 2>/dev/null\n> \n> It will error out if the directory does not exist, for some reason, e.g.\n> when you installed Git in your home directory via `make install` from a\n> fresh clone. So you'll have to cope with that contingency.\n\nOh, that's much more clever than mine. I did wonder if it would require\nthe containing directory to be writable, but it seems that \"--edit\" does\nnot do the usual lock-and-rename.\n\n-Peff\n"},{"id":"372427","messageId":"nycvar.QRO.7.76.6.1903251529110.41@tvgsbejvaqbjf.bet","threadId":"50787","inReplyTo":"20190322141925.olzzfjm5ytp2gwv7@glandium.org","subject":"Re: How to properly find git config in a libgit.a-using executable?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-25T14:37:36Z","receivedAt":"2019-03-25T14:38:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Mike,\n\nOn Fri, 22 Mar 2019, Mike Hommey wrote:\n\n> On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:\n> > Hi Peff & Mike,\n> >\n> > On Fri, 22 Mar 2019, Jeff King wrote:\n> >\n> > > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:\n> > >\n> > > > I thought of a few options (it's worth noting the helper is invoked in a\n> > > > way that makes $GIT_EXEC_PATH set, which can help a little):\n> > > > - spawn `$GIT_EXEC_PATH/git-config -l -z`, parse its output, and set the\n> > > >   internal config from that. That's the barbarian option.\n> > > > - build the helper with RUNTIME_PREFIX, and modify the RUNTIME_PREFIX\n> > > >   code to use $GIT_EXEC_PATH if it's set, rather than the path the\n> > > >   executable is in. That actually sounds reasonable enough that I'd send\n> > > >   a patch for git itself. But that doesn't quite address the nitpick case\n> > > >   where ETC_GITCONFIG could be either `/etc/gitconfig` or\n> > > >   `etc/gitconfig` depending how git was compiled, and there's no way to\n> > > >   know which is the right one.\n> > >\n> > > I'm not entirely sure I understand the problem, but it sounds like you\n> > > want to know the baked-in ETC_GITCONFIG for a built version of git (that\n> > > isn't necessarily the one that shares your build of libgit.a).\n> > >\n> > > There's no direct way to have Git print that out. It would be reasonable\n> > > to add one to rev-parse, I think.\n> > >\n> > > Barring that, here's a hack:\n> > >\n> > >   git config --system --show-origin --list -z |\n> > >   perl -lne '/^file:(.*?)\\0/ and print $1 and exit 0'\n> > >\n> > > If the file is empty, it won't print anything, of course. But then,\n> > > you'd know that it also has no config in it. :)\n> >\n> > How about\n> >\n> > \tGIT_EDITOR=echo git config --system -e 2>/dev/null\n> >\n> > It will error out if the directory does not exist, for some reason, e.g.\n> > when you installed Git in your home directory via `make install` from a\n> > fresh clone. So you'll have to cope with that contingency.\n>\n> Thank you both, I can probably work with this, although I might have to\n> alter the git init sequence.\n\nIf you spawn this, you should not need to alter any Git init sequence.\n\nAlso, I failed to mention that the error message when the directory does\nnot exist is quite helpful, too: it mentions the path to that directory.\n\nOh, and I forgot one really crucial thing: you want to set `LANG=C`, too,\nto make the output parseable.\n\n> I'm not sure my usecase needs git to cater for it more generally,\n> though.\n\nI guess the idea of Git is that the command-line interface is \"the API\".\nWith that idea, you should indeed not have to know the exact location of\nthe system config, as you can simply consume the output of `git config -l\n-z`.\n\nHowever, given all those really impressive performance wins we get out of\nall those conversions from shell/Perl to C, I am inclined to agree with\nyou: any remotely serious application that uses Git either has to access\nlibgit.a directly (even if that is discouraged), or has to have\nnon-trivial code inside Git to support their use cases (all those\n`for-each-ref` pattern enhancements we had to introduce, for example, to\nmake it remotely feasible for a 3rd-party application to work with the\namounts of branches we sometimes have to deal with, for example).\n\n> Who else uses libgit.a?\n\nI only know of cgit, the fast alternative to gitweb.\n\nCiao,\nDscho\n"}]}