All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Mike Hommey <mh@glandium.org>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: How to properly find git config in a libgit.a-using executable?
Date: Mon, 25 Mar 2019 15:37:36 +0100 (STD)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1903251529110.41@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20190322141925.olzzfjm5ytp2gwv7@glandium.org>

Hi Mike,

On Fri, 22 Mar 2019, Mike Hommey wrote:

> 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

  reply	other threads:[~2019-03-25 14:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 10:19 How to properly find git config in a libgit.a-using executable? Mike Hommey
2019-03-22  7:33 ` Jeff King
2019-03-22 13:39   ` Johannes Schindelin
2019-03-22 14:19     ` Mike Hommey
2019-03-25 14:37       ` Johannes Schindelin [this message]
2019-03-23  6:38     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1903251529110.41@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.