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. I'm not sure my usecase needs git to cater
for it more generally, though. Who else uses libgit.a?

Mike

Reply via email to