Thread (13 messages) flat view 13 messages, 6 authors, 2021-05-25

Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`

From: Jeff King <hidden>
Date: 2021-05-21 10:04:59

On Fri, May 21, 2021 at 01:55:32AM +0000, brian m. carlson wrote:
On 2021-05-20 at 09:51:25, Siavash wrote:
quoted
which is located in `contrib/credential/netrc`.

If I'm not mistaken, it's because it sets the `SCRIPT_PERL` environment variable here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13

But the Git Makefile un-sets environment variables here:
https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587

Also credential helpers in `contrib/credential` are not present in the
output of `git help -a`, is that a bug?
Things in contrib are not built by default because they don't
necessarily work everywhere.  For example, the osxkeychain credential
helper won't compile on Linux because the requisite shared libraries
are specific to macOS.  You'll need to compile them manually and install
them in a suitable location.
I agree with this, but just following up with a bit of a devil's
advocate: why not put osxkeychain into a regular "make install", but
make it conditional via a Makefile knob, like we do for other
platform-specific features?

The big reason most helpers are in contrib/ is because I wanted them to
be true third-party contributions that do not share any code with Git.
That avoids licensing questions when linking with libraries, and puts
them on an equal footing for people who want to implement a helper for
their favorite obscure tool.

It has lead to a somewhat funny situation, though. I don't really
consider osxkeychain well maintained. It's not built nor tested as part
our regular build. I wrote it long ago, but I never actually _used_ it
day-to-day, as I've never had a mac. It doesn't seem to have gotten any
commits since 2013.

And yet, my impression is that basically every Git user on macOS is
using it every day, because both Apple Git and homebrew build it by
default (and I think at least in the case of Apple Git, it's hard-coded
into the config). A little scary, but nobody seems to have complained. :)

I wonder if we could build it and run it through t0303 as part of the
mac CI process (though I recall at the time that it was really finicky
for automated testing; it wouldn't even run over an ssh session).

Likewise, we probably could be building and testing the libsecret ones
via the Linux CI job (I don't use those either myself, but presumably
they pass t0303).
Note that that location can be someplace like ~/bin, if that's in your
PATH.  For example, since the Debian packages don't yet ship the
libsecret credential helper, I've built it and placed it there.  Now
that I've done that, git help -a shows git credential-libsecret as an
option.
One curiosity is that:

  cd contrib/credential/netrc
  make install

builds and installs into .../libexec/git-core. And we don't seem to
include that in "git help -a" (it's not listed in our generated command
list, but nor is it an "external command" found in the $PATH).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help