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

[Felipe Contreras <felipe.contreras@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 24 2021, Felipe Contreras wrote:
> > Ævar Arnfjörð Bjarmason wrote:

> >> 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/.

> >> 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).
> >
> >> 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