Re: How to properly find git config in a libgit.a-using executable?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 25, 2019, 14:37 UTC
Message-ID: <nycvar.QRO.7.76.6.1903251529110.41@tvgsbejvaqbjf.bet>
In-Reply-To: <20190322141925.olzzfjm5ytp2gwv7@glandium.org>

Hi Mike,

On Fri, 22 Mar 2019, Mike Hommey wrote:

Show 44 quoted lines

> On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:
> > Hi Peff & Mike,
> >
> > On Fri, 22 Mar 2019, Jeff King wrote:
> >
> > > On Wed, Mar 20, 2019 at 07:19:41PM +0900, Mike Hommey wrote:
> > >
> > > > 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.
> > >
> > > I'm not entirely sure I understand the problem, but it sounds like you
> > > want to know the baked-in ETC_GITCONFIG for a built version of git (that
> > > isn't necessarily the one that shares your build of libgit.a).
> > >
> > > There's no direct way to have Git print that out. It would be reasonable
> > > to add one to rev-parse, I think.
> > >
> > > Barring that, here's a hack:
> > >
> > >   git config --system --show-origin --list -z |
> > >   perl -lne '/^file:(.*?)\0/ and print $1 and exit 0'
> > >
> > > If the file is empty, it won't print anything, of course. But then,
> > > you'd know that it also has no config in it. :)
> >
> > How about
> >
> > 	GIT_EDITOR=echo git config --system -e 2>/dev/null
> >
> > It will error out if the directory does not exist, for some reason, e.g.
> > when you installed Git in your home directory via `make install` from a
> > fresh clone. So you'll have to cope with that contingency.
>
> Thank you both, I can probably work with this, although I might have to
> alter the git init sequence.

If you spawn this, you should not need to alter any Git init sequence.

Also, I failed to mention that the error message when the directory does not exist is quite helpful, too: it mentions the path to that directory.

Oh, and I forgot one really crucial thing: you want to set `LANG=C`, too, to make the output parseable.

> I'm not sure my usecase needs git to cater for it more generally,
> though.

I guess the idea of Git is that the command-line interface is "the API". With that idea, you should indeed not have to know the exact location of the system config, as you can simply consume the output of `git config -l -z`.

However, given all those really impressive performance wins we get out of all those conversions from shell/Perl to C, I am inclined to agree with you: any remotely serious application that uses Git either has to access libgit.a directly (even if that is discouraged), or has to have non-trivial code inside Git to support their use cases (all those `for-each-ref` pattern enhancements we had to introduce, for example, to make it remotely feasible for a 3rd-party application to work with the amounts of branches we sometimes have to deal with, for example).

> Who else uses libgit.a?

I only know of cgit, the fast alternative to gitweb.

Ciao, Dscho