All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* How to properly find git config in a libgit.a-using executable?
@ 2019-03-20 10:19 Mike Hommey
  2019-03-22  7:33 ` Jeff King
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Hommey @ 2019-03-20 10:19 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to properly find git config in a libgit.a-using executable?
  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
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff King @ 2019-03-22  7:33 UTC (permalink / raw)
  To: Mike Hommey; +Cc: git

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. :)

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to properly find git config in a libgit.a-using executable?
  2019-03-22  7:33 ` Jeff King
@ 2019-03-22 13:39   ` Johannes Schindelin
  2019-03-22 14:19     ` Mike Hommey
  2019-03-23  6:38     ` Jeff King
  0 siblings, 2 replies; 6+ messages in thread
From: Johannes Schindelin @ 2019-03-22 13:39 UTC (permalink / raw)
  To: Jeff King; +Cc: Mike Hommey, git

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.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to properly find git config in a libgit.a-using executable?
  2019-03-22 13:39   ` Johannes Schindelin
@ 2019-03-22 14:19     ` Mike Hommey
  2019-03-25 14:37       ` Johannes Schindelin
  2019-03-23  6:38     ` Jeff King
  1 sibling, 1 reply; 6+ messages in thread
From: Mike Hommey @ 2019-03-22 14:19 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jeff King, git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to properly find git config in a libgit.a-using executable?
  2019-03-22 13:39   ` Johannes Schindelin
  2019-03-22 14:19     ` Mike Hommey
@ 2019-03-23  6:38     ` Jeff King
  1 sibling, 0 replies; 6+ messages in thread
From: Jeff King @ 2019-03-23  6:38 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Mike Hommey, git

On Fri, Mar 22, 2019 at 02:39:43PM +0100, Johannes Schindelin wrote:

> 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.

Oh, that's much more clever than mine. I did wonder if it would require
the containing directory to be writable, but it seems that "--edit" does
not do the usual lock-and-rename.

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: How to properly find git config in a libgit.a-using executable?
  2019-03-22 14:19     ` Mike Hommey
@ 2019-03-25 14:37       ` Johannes Schindelin
  0 siblings, 0 replies; 6+ messages in thread
From: Johannes Schindelin @ 2019-03-25 14:37 UTC (permalink / raw)
  To: Mike Hommey; +Cc: Jeff King, git

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-03-25 14:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-03-23  6:38     ` Jeff King

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.