Æ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
