Re: Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]")

On Mon, May 24 2021, Felipe Contreras wrote:

Ævar Arnfjörð Bjarmason wrote:

quoted

On Sun, May 23 2021, Felipe Contreras wrote:

quoted

Jeff King wrote:

quoted

I suspect that just opening a bug report against distro packages might
get some traction (especially if it comes with a patch to create the
extra package).

I have tried that; do doesn't work. If git developers have $x in
"contrib" it's for a reason.

quoted

I do wonder if packagers are hesitant to reach into
contrib/,

Of course they are! The word "contrib" has an obvious meaning.

[Minor edit to the quoted text to inline the link]:

quoted

This is precisely the reason why I tried to graduate
"contrib/completion" out of "contrib" to no avail:
https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/ (local)

Seems like that patch just got no replies at the time. FWIW I'd very
much be for it and would encourage you to re-submit it.

I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm
contributing to needless bikeshedding by mentioning that.

It is the best location because that's where completions go.

You can check the location bash-completion suggests to install
completions to:

  % pkg-config --variable=completionsdir bash-completion
  /usr/share/bash-completion/completions

In the case of zsh it's /usr/share/zsh/site-functions.

Additionally, if you install them in your home directory, it should be
$XDG_DATA_HOME/bash-completion/completions.

$XDG_DATA_HOME is $HOME/.local/share (analogous to /usr/share).

*Nod* I mean just because it ends up there in the FHS doesn't mean it's
 best for us to mirror that structure in git.git.

quoted

You apparently named it like that to match where distros usually install
it (/usr/share), but we also have docs there, locale, and the perl/
directory usually (well, at least on my distro) ends up there.

Distributions install them there, because that's where they are expected
(by bash-completion and zsh).

quoted

I wonder if just a top-level completion/* wouldn't be best, or if we
want to group them all together something like
optional/{completion,credential}/ or other name suggesting that these
are meant to interact with not-always-present 3rd party software. Maybe
integrations/* ?

extra/ is a better name.

However, there's already many things that are optional, like gitk and
git-gui, do they belong there too? For that matter locales are optional
too.

I think if such a decison to have an extra/ directory is made, it should
be orthogonal to the completion graduation.

The line I was attempting to draw was components that optionally
interact with optional 3rd party software.

The i18n framework isn't like that because we build it and interact with
ourselves, ditto for say PCRE. Optional, but /usr/bin/git is using it.

As opposed to bash/zsh completions, git will run just fine without
either of those shells installed.

The git-gui and gitk programs are also first-party software, just like
git-send-email or whatever. We just have knobs not to build them because
of the dependencies. It looks like we might be spinning them away from
git.git entirely in slow-motion, but so far they're first-class
commands.

quoted

For some of these names a general re-arrangement of contrib/* would be a
logical thing to follow, e.g. I think it would make sense to carve out
various ci/, contrib/coccinelle, Documentation/doc-diff,
check-builtins.sh etc. and other "only for supporting git.git
development" or "only called by our own Makefile(s)" into some
consistently named pattern.

Me too.

quoted

I'm also very much in favor of building and testing all of this software
by default, to the best of our ability. We've had some avoidable bitrot
e.g. in subtree and mw-to-git in the past, some of that is a pain to
test (e.g. requiring an installed MediaWiki), but we can usually
build/test some part of it (e.g. in that case, does it even compile as
Perl code?). In other cases we could compile/test things by default on
certain platforms if they're platform-specific.

Yeah, some spring cleaning would be good.

I'll put sending the patch in my unending to-do list.

Thanks.