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

Ævar Arnfjörð Bjarmason wrote:

On Mon, May 24 2021, Felipe Contreras wrote:

quoted

Ævar Arnfjörð Bjarmason wrote:

quoted

quoted

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.

It's not just that it ends there, it's how it ends there.

Right now the Arch Linux's git package does this:

  find contrib/ -name '.gitignore' -delete
  cp -a ./contrib/* "$pkgdir"/usr/share/git/

I would rather have an install-shared target to populate /usr/share/git.
Having a standar location for distributions would allow scripts to
simplify instructions, like:

  source /usr/share/git/completion/prompt.sh

Sure, how install-shared populates /usr/share/git is kind of orthogonal,
but it would make sense for install-shared to install stuff from shared/.

quoted

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.

git will also run fine without git-send-email, git-instaweb, and git-p4.

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.

I know what is the status quo, but when talking about suggestions for
improvement the status quo does not matter. Either the status quo makes
sense, or it doesn't.

I know gitk is "first-class", but *should* it? If so, why?

And I know git-completion.bash isn't "first-class", but shouldn't it? If
so, why not?

We even run git-completion.bash tests by default, gitk doesn't have
tests. We don't even track its history; all the commits are squashed
into a single "merge". And surely bash is a much more likely dependency
to be present in the user's system than Tcl/Tk.

So I don't really see what gitk has, that git-completion.bash hasn't.

Either both belong in extra/, or none of them do (and if one does an the
other doesn't, to me it's clear which is which).

Cheers.

-- 
Felipe Contreras