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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 21, 2021 at 01:55:32AM +0000, brian m. carlson wrote:

> On 2021-05-20 at 09:51:25, Siavash wrote:
> > 
> > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux