{"thread":{"id":"55746","subject":"[Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","startedAt":"2021-05-20T10:49:46Z","lastAt":"2021-05-25T10:37:20Z","messageCount":17,"participants":["Siavash","Jonathan Nieder","brian m. carlson","Jeff King","Felipe Contreras","Ævar Arnfjörð Bjarmason","Junio C Hamano","Bagas Sanjaya"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425077","messageId":"87k0nt3f8i.fsf@gmail.com","threadId":"55746","inReplyTo":null,"subject":"[Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Siavash","fromEmail":"siavash.askari.nasr@gmail.com","sentAt":"2021-05-20T09:51:25Z","receivedAt":"2021-05-20T10:49:46Z","isPatch":false,"sender":{"key":"siavash.askari.nasr@gmail.com","avatar":null},"body":"\nwhich is located in `contrib/credential/netrc`.\n\nIf I'm not mistaken, it's because it sets the `SCRIPT_PERL` environment variable here:\nhttps://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13\n\nBut the Git Makefile un-sets environment variables here:\nhttps://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587\n\nAlso credential helpers in `contrib/credential` are not present in the\noutput of `git help -a`, is that a bug?\n\nI'm using Git v2.31.1.\n"},{"id":"425143","messageId":"YKbJdiMNGaJAls4y@google.com","threadId":"55746","inReplyTo":"87k0nt3f8i.fsf@gmail.com","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2021-05-20T20:41:26Z","receivedAt":"2021-05-20T20:41:33Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nSiavash wrote:\n\n> [Subject: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`]\n>\n> which is located in `contrib/credential/netrc`.\n\nI'm missing some basic information:\n- what platform are you running on?\n- what commands did you use to install Git?\n- what are you trying to do?  That can help us with understanding the\n  problem or giving better advice tailored to the use case.  The netrc\n  credential helper is mostly meant as a demo, since libcurl supports\n  ~/.netrc on its own already.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"425176","messageId":"YKcTFDgW4etXFpOR@camp.crustytoothpaste.net","threadId":"55746","inReplyTo":"87k0nt3f8i.fsf@gmail.com","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-21T01:55:32Z","receivedAt":"2021-05-21T01:56:09Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-20 at 09:51:25, Siavash wrote:\n> \n> which is located in `contrib/credential/netrc`.\n> \n> If I'm not mistaken, it's because it sets the `SCRIPT_PERL` environment variable here:\n> https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13\n> \n> But the Git Makefile un-sets environment variables here:\n> https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587\n> \n> Also credential helpers in `contrib/credential` are not present in the\n> output of `git help -a`, is that a bug?\n\nThings in contrib are not built by default because they don't\nnecessarily work everywhere.  For example, the osxkeychain credential\nhelper won't compile on Linux because the requisite shared libraries\nare specific to macOS.  You'll need to compile them manually and install\nthem in a suitable location.\n\nNote that that location can be someplace like ~/bin, if that's in your\nPATH.  For example, since the Debian packages don't yet ship the\nlibsecret credential helper, I've built it and placed it there.  Now\nthat I've done that, git help -a shows git credential-libsecret as an\noption.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"425196","messageId":"YKeFxcTDp4tHSRu8@coredump.intra.peff.net","threadId":"55746","inReplyTo":"YKcTFDgW4etXFpOR@camp.crustytoothpaste.net","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-21T10:04:53Z","receivedAt":"2021-05-21T10:04:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 21, 2021 at 01:55:32AM +0000, brian m. carlson wrote:\n\n> On 2021-05-20 at 09:51:25, Siavash wrote:\n> > \n> > which is located in `contrib/credential/netrc`.\n> > \n> > If I'm not mistaken, it's because it sets the `SCRIPT_PERL` environment variable here:\n> > https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13\n> > \n> > But the Git Makefile un-sets environment variables here:\n> > https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587\n> > \n> > Also credential helpers in `contrib/credential` are not present in the\n> > output of `git help -a`, is that a bug?\n> \n> Things in contrib are not built by default because they don't\n> necessarily work everywhere.  For example, the osxkeychain credential\n> helper won't compile on Linux because the requisite shared libraries\n> are specific to macOS.  You'll need to compile them manually and install\n> them in a suitable location.\n\nI agree with this, but just following up with a bit of a devil's\nadvocate: why not put osxkeychain into a regular \"make install\", but\nmake it conditional via a Makefile knob, like we do for other\nplatform-specific features?\n\nThe big reason most helpers are in contrib/ is because I wanted them to\nbe true third-party contributions that do not share any code with Git.\nThat avoids licensing questions when linking with libraries, and puts\nthem on an equal footing for people who want to implement a helper for\ntheir favorite obscure tool.\n\nIt has lead to a somewhat funny situation, though. I don't really\nconsider osxkeychain well maintained. It's not built nor tested as part\nour regular build. I wrote it long ago, but I never actually _used_ it\nday-to-day, as I've never had a mac. It doesn't seem to have gotten any\ncommits since 2013.\n\nAnd yet, my impression is that basically every Git user on macOS is\nusing it every day, because both Apple Git and homebrew build it by\ndefault (and I think at least in the case of Apple Git, it's hard-coded\ninto the config). A little scary, but nobody seems to have complained. :)\n\nI wonder if we could build it and run it through t0303 as part of the\nmac CI process (though I recall at the time that it was really finicky\nfor automated testing; it wouldn't even run over an ssh session).\n\nLikewise, we probably could be building and testing the libsecret ones\nvia the Linux CI job (I don't use those either myself, but presumably\nthey pass t0303).\n\n> Note that that location can be someplace like ~/bin, if that's in your\n> PATH.  For example, since the Debian packages don't yet ship the\n> libsecret credential helper, I've built it and placed it there.  Now\n> that I've done that, git help -a shows git credential-libsecret as an\n> option.\n\nOne curiosity is that:\n\n  cd contrib/credential/netrc\n  make install\n\nbuilds and installs into .../libexec/git-core. And we don't seem to\ninclude that in \"git help -a\" (it's not listed in our generated command\nlist, but nor is it an \"external command\" found in the $PATH).\n\n-Peff\n"},{"id":"425197","messageId":"YKeGP6STQMy63tEJ@coredump.intra.peff.net","threadId":"55746","inReplyTo":"87k0nt3f8i.fsf@gmail.com","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-21T10:06:55Z","receivedAt":"2021-05-21T10:07:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 20, 2021 at 02:21:25PM +0430, Siavash wrote:\n\n> If I'm not mistaken, it's because it sets the `SCRIPT_PERL` environment variable here:\n> https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/contrib/credential/netrc/Makefile#L13\n> \n> But the Git Makefile un-sets environment variables here:\n> https://github.com/git/git/blob/88dd4282d949cdafff516650c1be8aaf4d67983f/Makefile#L587\n\nThat part is OK. The netrc build runs \"make SCRIPT_PERL=...\", which will\noverride any instances where it is set in the top-level Makefile.\n\nSo just doing:\n\n  cd contrib/credential/netrc\n  make install\n\nshould be enough to make it work.\n\n-Peff\n"},{"id":"425198","messageId":"87zgwocri7.fsf@gmail.com","threadId":"55746","inReplyTo":"YKbJdiMNGaJAls4y@google.com","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Siavash","fromEmail":"siavash.askari.nasr@gmail.com","sentAt":"2021-05-21T10:26:09Z","receivedAt":"2021-05-21T10:26:31Z","isPatch":false,"sender":{"key":"siavash.askari.nasr@gmail.com","avatar":null},"body":"\nHi,\n\nOn 2021-05-21 01:11:26 +0430, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> I'm missing some basic information:\n> - what platform are you running on?\n\nI'm using Arch Linux with Linux v5.12.5-arch1-1.\n\n> - what commands did you use to install Git?\n\n`sudo pacman -S git`\n\n> - what are you trying to do?  That can help us with understanding the\n>   problem or giving better advice tailored to the use case.  The netrc\n>   credential helper is mostly meant as a demo, since libcurl supports\n>   ~/.netrc on its own already.\n\nI wanted to use `git-credential-netrc.perl` to use `.authinfo.gpg` as\ngit credential. The `gitcredentials` manual said use:\n`git config --global credential-helper foo`\nfor using credential helpers. It also mentioned that `git credential-`\ngets prepended to the external helpers. So I expected:\n`git config --global credential-helper 'netrc'`\nto work.\n\nI can use it as a helper if I use an absolute path:\n'/usr/share/git/credential/netrc/git-credential-netrc.perl'\n\nAfter looking at the `PKGBUILD` file in Arch Linux's git repository, I\nfound out that they are not making \"netrc\".\nhttps://github.com/archlinux/svntogit-packages/blob/4864e39da0bc99e373f3cb728272a93d66b58cd6/trunk/PKGBUILD#L63-L64\n\nSo this is not a bug. As Jeff King mentioned as well.\nI should have checked the `PKGBUILD`.\n\nThe output of `git --exec-path` is `/usr/lib/git-core`. And there are\nother helpers there(made by Arch Linux).\nThis is the output of `lsd /usr/lib/git-core/ | rg credential`:\ngit-credential\ngit-credential-cache\ngit-credential-cache--daemon\ngit-credential-gnome-keyring\ngit-credential-libsecret\ngit-credential-store\n\nI expected the third-party helpers to be in the output of `git help -a`\nas mentioned in the manual. They are not in the `PATH`, but they are in\ngit's `exec-path`.  So shouldn't they be printed in the help output?\n"},{"id":"425243","messageId":"YKgzvFHOcUgPjbj/@camp.crustytoothpaste.net","threadId":"55746","inReplyTo":"YKeFxcTDp4tHSRu8@coredump.intra.peff.net","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-21T22:27:08Z","receivedAt":"2021-05-21T22:27:44Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-21 at 10:04:53, Jeff King wrote:\n> On Fri, May 21, 2021 at 01:55:32AM +0000, brian m. carlson wrote:\n> > Things in contrib are not built by default because they don't\n> > necessarily work everywhere.  For example, the osxkeychain credential\n> > helper won't compile on Linux because the requisite shared libraries\n> > are specific to macOS.  You'll need to compile them manually and install\n> > them in a suitable location.\n> \n> I agree with this, but just following up with a bit of a devil's\n> advocate: why not put osxkeychain into a regular \"make install\", but\n> make it conditional via a Makefile knob, like we do for other\n> platform-specific features?\n\nSure, let's do it.\n\nFor osxkeychain, it's probably pretty simple to always build it, since\nmacOS will always have the appropriate libraries if the compiler is\ninstalled.  I would be in favor of also building by default on Linux and\nhaving a Makefile knob to disable that, since the requisite libraries are\na part of nearly every distribution and doing so will spur distros to\nship it, which many do not.\n\n> And yet, my impression is that basically every Git user on macOS is\n> using it every day, because both Apple Git and homebrew build it by\n> default (and I think at least in the case of Apple Git, it's hard-coded\n> into the config). A little scary, but nobody seems to have complained. :)\n> \n> I wonder if we could build it and run it through t0303 as part of the\n> mac CI process (though I recall at the time that it was really finicky\n> for automated testing; it wouldn't even run over an ssh session).\n> \n> Likewise, we probably could be building and testing the libsecret ones\n> via the Linux CI job (I don't use those either myself, but presumably\n> they pass t0303).\n\nRunning the tests will be harder.  macOS, I believe, requires an\ninteractive session to have the keychain unlocked, and on Linux, you\nrequire gnome-keyring or an equivalent daemon running, which practically\nmeans that you need a desktop session.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"425388","messageId":"YKqzj/DZU8m9AaI/@coredump.intra.peff.net","threadId":"55746","inReplyTo":"YKgzvFHOcUgPjbj/@camp.crustytoothpaste.net","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-23T19:57:03Z","receivedAt":"2021-05-23T20:07:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 21, 2021 at 10:27:08PM +0000, brian m. carlson wrote:\n\n> > I agree with this, but just following up with a bit of a devil's\n> > advocate: why not put osxkeychain into a regular \"make install\", but\n> > make it conditional via a Makefile knob, like we do for other\n> > platform-specific features?\n> \n> Sure, let's do it.\n> \n> For osxkeychain, it's probably pretty simple to always build it, since\n> macOS will always have the appropriate libraries if the compiler is\n> installed.\n\nHmm. So I tried just building oxskeychain in our CI via contrib, and it\nfails. :(\n\nIt looks like it's OK with clang, but not gcc:\n\n  https://github.com/peff/git/runs/2647748209?check_suite_focus=true\n\nMaybe nobody cares about gcc for this use, but I'm inclined to leave it\nto somebody who actually runs macOS to poke at further.\n\n> I would be in favor of also building by default on Linux and\n> having a Makefile knob to disable that, since the requisite libraries are\n> a part of nearly every distribution and doing so will spur distros to\n> ship it, which many do not.\n\nI assume you mean contrib/credential/libsecret here. I'd worry that\nflipping it on by default is annoying for people who build from source.\nI don't have dev libraries for things like libsecret or glib on my\ndevelopment system[1], and I'd be surprised if most server-oriented\nmachines have even the non-dev versions.\n\nWhich isn't an argument against making it easier to build them from the\nmain Makefile, but it seems like having them on by default (with a\nNO_LIBSECRET) would cause more surprises than the other way around\n(USE_LIBSECRET or similar).\n\nI suspect that just opening a bug report against distro packages might\nget some traction (especially if it comes with a patch to create the\nextra package). I do wonder if packagers are hesitant to reach into\ncontrib/, not knowing how well maintained the contents are (to be\nhonest, I am not confident in how well maintained they are, either; it\nmight be helpful if somebody who routinely used each helper stepped up\nto say that they would maintain it).\n\n-Peff\n\n[1] I was actually surprised I had libsecret installed at all.\n    Apparently pinentry-gtk2 links against it, which I have for use with\n    gpg. But my system might not be considered typical anyway, as I\n    don't use any kind of \"desktop environment\".\n"},{"id":"425395","messageId":"60ab17018efee_1691c20832@natae.notmuch","threadId":"55746","inReplyTo":"YKqzj/DZU8m9AaI/@coredump.intra.peff.net","subject":"Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-24T03:01:21Z","receivedAt":"2021-05-24T03:01:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n\n> I suspect that just opening a bug report against distro packages might\n> get some traction (especially if it comes with a patch to create the\n> extra package).\n\nI have tried that; do doesn't work. If git developers have $x in\n\"contrib\" it's for a reason.\n\n> I do wonder if packagers are hesitant to reach into\n> contrib/,\n\nOf course they are! The word \"contrib\" has an obvious meaning.\n\nThis is precisely the reason why I tried to graduate \"contrib/completion\"\nout of \"contrib\" to no avail [1].\n\nIf you want to install anything from \"contrib\" by default, it should be\n\"contrib/completion\" first, which is already very well tested, and\nshipped by many distributions. I would move it outside \"contrib\", to be\nsemantically consistent.\n\nThen maybe \"contrib/credential\", sure, following \"contrib/completion\".\n\nBut to do a mish-mash between \"/\" and \"/contrib\". Does not make sense.\n\nYou can't eat your cake and have it too.\n\nEither they are contributed, or they aren't.\n\nCheers.\n\n[1] https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/\n\n> [1] I was actually surprised I had libsecret installed at all.\n>     Apparently pinentry-gtk2 links against it, which I have for use with\n>     gpg. But my system might not be considered typical anyway, as I\n>     don't use any kind of \"desktop environment\".\n\nUnless you have a backend (like gnome-keyring) libsecret is useless.\n\nCan you do \"secret-tool lookup *\" and fetch any of your passwords?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"425425","messageId":"87o8d0o2or.fsf@evledraar.gmail.com","threadId":"55746","inReplyTo":"60ab17018efee_1691c20832@natae.notmuch","subject":"Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-24T10:05:34Z","receivedAt":"2021-05-24T10:18:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, May 23 2021, Felipe Contreras wrote:\n\n> Jeff King wrote:\n>\n>> I suspect that just opening a bug report against distro packages might\n>> get some traction (especially if it comes with a patch to create the\n>> extra package).\n>\n> I have tried that; do doesn't work. If git developers have $x in\n> \"contrib\" it's for a reason.\n>\n>> I do wonder if packagers are hesitant to reach into\n>> contrib/,\n>\n> Of course they are! The word \"contrib\" has an obvious meaning.\n\n[Minor edit to the quoted text to inline the link]:\n\n> This is precisely the reason why I tried to graduate\n> \"contrib/completion\" out of \"contrib\" to no avail:\n> https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/\n\nSeems like that patch just got no replies at the time. FWIW I'd very\nmuch be for it and would encourage you to re-submit it.\n\nI'm not sure s/shared/contrib/g is the best naming though, but maybe I'm\ncontributing to needless bikeshedding by mentioning that.\n\nYou apparently named it like that to match where distros usually install\nit (/usr/share), but we also have docs there, locale, and the perl/\ndirectory usually (well, at least on my distro) ends up there.\n\nI wonder if just a top-level completion/* wouldn't be best, or if we\nwant to group them all together something like\noptional/{completion,credential}/ or other name suggesting that these\nare meant to interact with not-always-present 3rd party software. Maybe\nintegrations/* ?\n\nFor some of these names a general re-arrangement of contrib/* would be a\nlogical thing to follow, e.g. I think it would make sense to carve out\nvarious ci/, contrib/coccinelle, Documentation/doc-diff,\ncheck-builtins.sh etc. and other \"only for supporting git.git\ndevelopment\" or \"only called by our own Makefile(s)\" into some\nconsistently named pattern.\n\nI'm also very much in favor of building and testing all of this software\nby default, to the best of our ability. We've had some avoidable bitrot\ne.g. in subtree and mw-to-git in the past, some of that is a pain to\ntest (e.g. requiring an installed MediaWiki), but we can usually\nbuild/test some part of it (e.g. in that case, does it even compile as\nPerl code?). In other cases we could compile/test things by default on\ncertain platforms if they're platform-specific.\n"},{"id":"425440","messageId":"60abe0b32dfa1_1b2092081d@natae.notmuch","threadId":"55746","inReplyTo":"87o8d0o2or.fsf@evledraar.gmail.com","subject":"RE: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-24T17:21:55Z","receivedAt":"2021-05-24T17:21:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Sun, May 23 2021, Felipe Contreras wrote:\n> \n> > Jeff King wrote:\n> >\n> >> I suspect that just opening a bug report against distro packages might\n> >> get some traction (especially if it comes with a patch to create the\n> >> extra package).\n> >\n> > I have tried that; do doesn't work. If git developers have $x in\n> > \"contrib\" it's for a reason.\n> >\n> >> I do wonder if packagers are hesitant to reach into\n> >> contrib/,\n> >\n> > Of course they are! The word \"contrib\" has an obvious meaning.\n> \n> [Minor edit to the quoted text to inline the link]:\n> \n> > This is precisely the reason why I tried to graduate\n> > \"contrib/completion\" out of \"contrib\" to no avail:\n> > https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/\n> \n> Seems like that patch just got no replies at the time. FWIW I'd very\n> much be for it and would encourage you to re-submit it.\n> \n> I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm\n> contributing to needless bikeshedding by mentioning that.\n\nIt is the best location because that's where completions go.\n\nYou can check the location bash-completion suggests to install\ncompletions to:\n\n  % pkg-config --variable=completionsdir bash-completion\n  /usr/share/bash-completion/completions\n\nIn the case of zsh it's /usr/share/zsh/site-functions.\n\nAdditionally, if you install them in your home directory, it should be\n$XDG_DATA_HOME/bash-completion/completions.\n\n$XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).\n\n> You apparently named it like that to match where distros usually install\n> it (/usr/share), but we also have docs there, locale, and the perl/\n> directory usually (well, at least on my distro) ends up there.\n\nDistributions install them there, because that's where they are expected\n(by bash-completion and zsh).\n\n> I wonder if just a top-level completion/* wouldn't be best, or if we\n> want to group them all together something like\n> optional/{completion,credential}/ or other name suggesting that these\n> are meant to interact with not-always-present 3rd party software. Maybe\n> integrations/* ?\n\nextra/ is a better name.\n\nHowever, there's already many things that are optional, like gitk and\ngit-gui, do they belong there too? For that matter locales are optional\ntoo.\n\nI think if such a decison to have an extra/ directory is made, it should\nbe orthogonal to the completion graduation.\n\n> For some of these names a general re-arrangement of contrib/* would be a\n> logical thing to follow, e.g. I think it would make sense to carve out\n> various ci/, contrib/coccinelle, Documentation/doc-diff,\n> check-builtins.sh etc. and other \"only for supporting git.git\n> development\" or \"only called by our own Makefile(s)\" into some\n> consistently named pattern.\n\nMe too.\n\n> I'm also very much in favor of building and testing all of this software\n> by default, to the best of our ability. We've had some avoidable bitrot\n> e.g. in subtree and mw-to-git in the past, some of that is a pain to\n> test (e.g. requiring an installed MediaWiki), but we can usually\n> build/test some part of it (e.g. in that case, does it even compile as\n> Perl code?). In other cases we could compile/test things by default on\n> certain platforms if they're platform-specific.\n\nYeah, some spring cleaning would be good.\n\nI'll put sending the patch in my unending to-do list.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"425470","messageId":"87a6ojogvp.fsf@evledraar.gmail.com","threadId":"55746","inReplyTo":"60abe0b32dfa1_1b2092081d@natae.notmuch","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-24T23:18:28Z","receivedAt":"2021-05-24T23:23:59Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, May 24 2021, Felipe Contreras wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>> \n>> On Sun, May 23 2021, Felipe Contreras wrote:\n>> \n>> > Jeff King wrote:\n>> >\n>> >> I suspect that just opening a bug report against distro packages might\n>> >> get some traction (especially if it comes with a patch to create the\n>> >> extra package).\n>> >\n>> > I have tried that; do doesn't work. If git developers have $x in\n>> > \"contrib\" it's for a reason.\n>> >\n>> >> I do wonder if packagers are hesitant to reach into\n>> >> contrib/,\n>> >\n>> > Of course they are! The word \"contrib\" has an obvious meaning.\n>> \n>> [Minor edit to the quoted text to inline the link]:\n>> \n>> > This is precisely the reason why I tried to graduate\n>> > \"contrib/completion\" out of \"contrib\" to no avail:\n>> > https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/\n>> \n>> Seems like that patch just got no replies at the time. FWIW I'd very\n>> much be for it and would encourage you to re-submit it.\n>> \n>> I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm\n>> contributing to needless bikeshedding by mentioning that.\n>\n> It is the best location because that's where completions go.\n>\n> You can check the location bash-completion suggests to install\n> completions to:\n>\n>   % pkg-config --variable=completionsdir bash-completion\n>   /usr/share/bash-completion/completions\n>\n> In the case of zsh it's /usr/share/zsh/site-functions.\n>\n> Additionally, if you install them in your home directory, it should be\n> $XDG_DATA_HOME/bash-completion/completions.\n>\n> $XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).\n\n*Nod* I mean just because it ends up there in the FHS doesn't mean it's\n best for us to mirror that structure in git.git.\n\n>> You apparently named it like that to match where distros usually install\n>> it (/usr/share), but we also have docs there, locale, and the perl/\n>> directory usually (well, at least on my distro) ends up there.\n>\n> Distributions install them there, because that's where they are expected\n> (by bash-completion and zsh).\n>\n>> I wonder if just a top-level completion/* wouldn't be best, or if we\n>> want to group them all together something like\n>> optional/{completion,credential}/ or other name suggesting that these\n>> are meant to interact with not-always-present 3rd party software. Maybe\n>> integrations/* ?\n>\n> extra/ is a better name.\n>\n> However, there's already many things that are optional, like gitk and\n> git-gui, do they belong there too? For that matter locales are optional\n> too.\n>\n> I think if such a decison to have an extra/ directory is made, it should\n> be orthogonal to the completion graduation.\n\nThe line I was attempting to draw was components that optionally\ninteract with optional 3rd party software.\n\nThe i18n framework isn't like that because we build it and interact with\nourselves, ditto for say PCRE. Optional, but /usr/bin/git is using it.\n\nAs opposed to bash/zsh completions, git will run just fine without\neither of those shells installed.\n\nThe git-gui and gitk programs are also first-party software, just like\ngit-send-email or whatever. We just have knobs not to build them because\nof the dependencies. It looks like we might be spinning them away from\ngit.git entirely in slow-motion, but so far they're first-class\ncommands.\n\n>> For some of these names a general re-arrangement of contrib/* would be a\n>> logical thing to follow, e.g. I think it would make sense to carve out\n>> various ci/, contrib/coccinelle, Documentation/doc-diff,\n>> check-builtins.sh etc. and other \"only for supporting git.git\n>> development\" or \"only called by our own Makefile(s)\" into some\n>> consistently named pattern.\n>\n> Me too.\n>\n>> I'm also very much in favor of building and testing all of this software\n>> by default, to the best of our ability. We've had some avoidable bitrot\n>> e.g. in subtree and mw-to-git in the past, some of that is a pain to\n>> test (e.g. requiring an installed MediaWiki), but we can usually\n>> build/test some part of it (e.g. in that case, does it even compile as\n>> Perl code?). In other cases we could compile/test things by default on\n>> certain platforms if they're platform-specific.\n>\n> Yeah, some spring cleaning would be good.\n>\n> I'll put sending the patch in my unending to-do list.\n\nThanks.\n"},{"id":"425476","messageId":"60ac51a7ecf74_1f8f720843@natae.notmuch","threadId":"55746","inReplyTo":"87a6ojogvp.fsf@evledraar.gmail.com","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-25T01:23:51Z","receivedAt":"2021-05-25T01:24:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, May 24 2021, Felipe Contreras wrote:\n> > Ævar Arnfjörð Bjarmason wrote:\n\n> >> I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm\n> >> contributing to needless bikeshedding by mentioning that.\n> >\n> > It is the best location because that's where completions go.\n> >\n> > You can check the location bash-completion suggests to install\n> > completions to:\n> >\n> >   % pkg-config --variable=completionsdir bash-completion\n> >   /usr/share/bash-completion/completions\n> >\n> > In the case of zsh it's /usr/share/zsh/site-functions.\n> >\n> > Additionally, if you install them in your home directory, it should be\n> > $XDG_DATA_HOME/bash-completion/completions.\n> >\n> > $XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).\n> \n> *Nod* I mean just because it ends up there in the FHS doesn't mean it's\n>  best for us to mirror that structure in git.git.\n\nIt's not just that it ends there, it's how it ends there.\n\nRight now the Arch Linux's git package does this:\n\n  find contrib/ -name '.gitignore' -delete\n  cp -a ./contrib/* \"$pkgdir\"/usr/share/git/\n\nI would rather have an install-shared target to populate /usr/share/git.\nHaving a standar location for distributions would allow scripts to\nsimplify instructions, like:\n\n  source /usr/share/git/completion/prompt.sh\n\nSure, how install-shared populates /usr/share/git is kind of orthogonal,\nbut it would make sense for install-shared to install stuff from shared/.\n\n> >> You apparently named it like that to match where distros usually install\n> >> it (/usr/share), but we also have docs there, locale, and the perl/\n> >> directory usually (well, at least on my distro) ends up there.\n> >\n> > Distributions install them there, because that's where they are expected\n> > (by bash-completion and zsh).\n> >\n> >> I wonder if just a top-level completion/* wouldn't be best, or if we\n> >> want to group them all together something like\n> >> optional/{completion,credential}/ or other name suggesting that these\n> >> are meant to interact with not-always-present 3rd party software. Maybe\n> >> integrations/* ?\n> >\n> > extra/ is a better name.\n> >\n> > However, there's already many things that are optional, like gitk and\n> > git-gui, do they belong there too? For that matter locales are optional\n> > too.\n> >\n> > I think if such a decison to have an extra/ directory is made, it should\n> > be orthogonal to the completion graduation.\n> \n> The line I was attempting to draw was components that optionally\n> interact with optional 3rd party software.\n> \n> The i18n framework isn't like that because we build it and interact with\n> ourselves, ditto for say PCRE. Optional, but /usr/bin/git is using it.\n> \n> As opposed to bash/zsh completions, git will run just fine without\n> either of those shells installed.\n\ngit will also run fine without git-send-email, git-instaweb, and git-p4.\n\n> The git-gui and gitk programs are also first-party software, just like\n> git-send-email or whatever. We just have knobs not to build them because\n> of the dependencies. It looks like we might be spinning them away from\n> git.git entirely in slow-motion, but so far they're first-class\n> commands.\n\nI know what is the status quo, but when talking about suggestions for\nimprovement the status quo does not matter. Either the status quo makes\nsense, or it doesn't.\n\nI know gitk is \"first-class\", but *should* it? If so, why?\n\nAnd I know git-completion.bash isn't \"first-class\", but shouldn't it? If\nso, why not?\n\nWe even run git-completion.bash tests by default, gitk doesn't have\ntests. We don't even track its history; all the commits are squashed\ninto a single \"merge\". And surely bash is a much more likely dependency\nto be present in the user's system than Tcl/Tk.\n\nSo I don't really see what gitk has, that git-completion.bash hasn't.\n\nEither both belong in extra/, or none of them do (and if one does an the\nother doesn't, to me it's clear which is which).\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"425492","messageId":"xmqqtumrfgqx.fsf@gitster.g","threadId":"55746","inReplyTo":"87o8d0o2or.fsf@evledraar.gmail.com","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-25T06:51:34Z","receivedAt":"2021-05-25T06:51:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I wonder if just a top-level completion/* wouldn't be best, or if we\n> want to group them all together something like\n> optional/{completion,credential}/ or other name suggesting that these\n> are meant to interact with not-always-present 3rd party software. Maybe\n> integrations/* ?\n\nAdd-ons?\n\nI think dispelling the conception by distro people must begin with\nan update to contrib/README where it clearly says these are\n\"contributed software\" that are not part of \"Git\".  They are not\nsomething we stand behind like what we have in the rest of the\nsource tree.\n\nAlso, the description there is rather stale.  For example, the last\nparagraph must go as its entirety.  The ecosystem has expanded\nthousand-fold since the document was written, and we no longer\nencourage people to add new things to contrib/ directory at all.  We\ninstead encourage them to write and sell their ware on their own\nmerit alone, without planning to \"borrow\" authority and gain undue\nadvantage over its competitors by being in the contrib/ area in our\ntree.\n.\n"},{"id":"425498","messageId":"8c08ee45-d7e4-b816-e883-a18dfa69fbc1@gmail.com","threadId":"55746","inReplyTo":"xmqqtumrfgqx.fsf@gitster.g","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-25T07:31:27Z","receivedAt":"2021-05-25T07:31:40Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 25/05/21 13.51, Junio C Hamano wrote:\n> I think dispelling the conception by distro people must begin with\n> an update to contrib/README where it clearly says these are\n> \"contributed software\" that are not part of \"Git\".  They are not\n> something we stand behind like what we have in the rest of the\n> source tree.\n> \nArchlinux packagers did remove contrib/ because they don't interest\non it [1]:\n\n> Right now the Arch Linux's git package does this:\n> \n>   find contrib/ -name '.gitignore' -delete\n>   cp -a ./contrib/* \"$pkgdir\"/usr/share/git/\n\n> Also, the description there is rather stale.  For example, the last\n> paragraph must go as its entirety.  The ecosystem has expanded\n> thousand-fold since the document was written, and we no longer\n> encourage people to add new things to contrib/ directory at all.  We\n> instead encourage them to write and sell their ware on their own\n> merit alone, without planning to \"borrow\" authority and gain undue\n> advantage over its competitors by being in the contrib/ area in our\n> tree.\n> .\n> \n\nSo basically we should deprecate contrib/, and then after next few\nreleases we proceed to remove it, right?\n\n[1]: https://lore.kernel.org/git/60ac51a7ecf74_1f8f720843@natae.notmuch/\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"425502","messageId":"60acbde4621f1_2257a20819@natae.notmuch","threadId":"55746","inReplyTo":"8c08ee45-d7e4-b816-e883-a18dfa69fbc1@gmail.com","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-25T09:05:40Z","receivedAt":"2021-05-25T09:05:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Bagas Sanjaya wrote:\n> On 25/05/21 13.51, Junio C Hamano wrote:\n> > I think dispelling the conception by distro people must begin with\n> > an update to contrib/README where it clearly says these are\n> > \"contributed software\" that are not part of \"Git\".  They are not\n> > something we stand behind like what we have in the rest of the\n> > source tree.\n> > \n> Archlinux packagers did remove contrib/ because they don't interest\n> on it [1]:\n\nHuh? The whole content of contrib/ is installed in /usr/share/git/ [1]\n\nSome stuff like git-completion.bash is installed *twice*.\n\nOnce in `/usr/share/bash-completion/completions/git` and another in\n`/usr/share/git/completion/git-completion.bash`.\n\n> > Right now the Arch Linux's git package does this:\n> > \n> >   find contrib/ -name '.gitignore' -delete\n> >   cp -a ./contrib/* \"$pkgdir\"/usr/share/git/\n> \n> > Also, the description there is rather stale.  For example, the last\n> > paragraph must go as its entirety.  The ecosystem has expanded\n> > thousand-fold since the document was written, and we no longer\n> > encourage people to add new things to contrib/ directory at all.  We\n> > instead encourage them to write and sell their ware on their own\n> > merit alone, without planning to \"borrow\" authority and gain undue\n> > advantage over its competitors by being in the contrib/ area in our\n> > tree.\n> > .\n> > \n> \n> So basically we should deprecate contrib/, and then after next few\n> releases we proceed to remove it, right?\n\nI tried that many years ago[2]. Didn't work.\n\n[1] https://archlinux.org/packages/extra/x86_64/git/#filelink\n[2] https://lore.kernel.org/git/1399662703-355-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"425505","messageId":"60acd2f76e290_2257a208e9@natae.notmuch","threadId":"55746","inReplyTo":"xmqqtumrfgqx.fsf@gitster.g","subject":"Re: Renaming \"non-contrib\" things out of contrib/* (was \"Re: [Bug] git-credential-netrc.perl[...]\")","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-25T10:35:35Z","receivedAt":"2021-05-25T10:37:20Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> \n> > I wonder if just a top-level completion/* wouldn't be best, or if we\n> > want to group them all together something like\n> > optional/{completion,credential}/ or other name suggesting that these\n> > are meant to interact with not-always-present 3rd party software. Maybe\n> > integrations/* ?\n> \n> Add-ons?\n\nAn add-on extends the functionality of the core. These are not add-ons.\n\n> I think dispelling the conception by distro people must begin with\n> an update to contrib/README where it clearly says these are\n> \"contributed software\" that are not part of \"Git\".  They are not\n> something we stand behind like what we have in the rest of the\n> source tree.\n\nThey know what the README says.\n\nBut they also know what the README says is not true. git-completion.bash\nis completely fine for wide-spread use, and in fact, it's already used\nwidely. They are not going to remove\n`/usr/share/bash-completion/completions/git` just because upstream\ndevelopers write something innacurate in contrib/README.\n\nTheir first responsibility is to provide the most usable system they can\nto their users. git completions for bash is essential towards that goal.\n\nAs long as the README contains innacurate information they will be\nforced to ignore it, and keep installing valuable stuff from contrib/ at\ntheir own discretion.\n\n> We instead encourage them to write and sell their ware on their own\n> merit alone, without planning to \"borrow\" authority and gain undue\n> advantage over its competitors by being in the contrib/ area in our\n> tree.\n\nThey why did you reject my git-related tool[1], and yet accepted a\ndirect competitor git-contacts[2]? It certainly looks like you have\nundue advantage to one tool over the other.\n\nThere's is also hg-to-git, a competition of git-remote-hg.\n\nAnd for that matter git-completion.zsh, a tool I created, and is now in\ncompetition with git-completion[3].\n\nIt would be nice if what was stated above was true, but alas it's not.\n\nCheers.\n\n[1] https://lore.kernel.org/git/CAMP44s2+rNG+VPVJ82UsfrmHugnUwBVJfYF5QRVn0=JC061RFg@mail.gmail.com/\n[2] https://lore.kernel.org/git/7vobamgqqh.fsf@alter.siamese.dyndns.org/\n[3] https://github.com/felipec/git-completion\n\n-- \nFelipe Contreras"}]}