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

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

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

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