git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Siavash <siavash.askari.nasr@gmail.com>, git@vger.kernel.org
Subject: Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`
Date: Fri, 21 May 2021 06:04:53 -0400	[thread overview]
Message-ID: <YKeFxcTDp4tHSRu8@coredump.intra.peff.net> (raw)
In-Reply-To: <YKcTFDgW4etXFpOR@camp.crustytoothpaste.net>

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

  reply	other threads:[~2021-05-21 10:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20  9:51 [Bug] git-credential-netrc.perl is not built and is not available in `exec-path` Siavash
2021-05-20 20:41 ` Jonathan Nieder
2021-05-21 10:26   ` Siavash
2021-05-21  1:55 ` brian m. carlson
2021-05-21 10:04   ` Jeff King [this message]
2021-05-21 22:27     ` brian m. carlson
2021-05-23 19:57       ` Jeff King
2021-05-24  3:01         ` Felipe Contreras
2021-05-24 10:05           ` Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]") Ævar Arnfjörð Bjarmason
2021-05-24 17:21             ` Felipe Contreras
2021-05-24 23:18               ` Ævar Arnfjörð Bjarmason
2021-05-25  1:23                 ` Felipe Contreras
2021-05-25  6:51             ` Junio C Hamano
2021-05-25  7:31               ` Bagas Sanjaya
2021-05-25  9:05                 ` Felipe Contreras
2021-05-25 10:35               ` Felipe Contreras
2021-05-21 10:06 ` [Bug] git-credential-netrc.perl is not built and is not available in `exec-path` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=YKeFxcTDp4tHSRu8@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=siavash.askari.nasr@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).