mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <>
To: "Ævar Arnfjörð Bjarmason" <>,
	"Felipe Contreras" <>
Cc: Jeff King <>,
	"brian m. carlson" <>,
	Siavash <>,
Subject: Re: Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]")
Date: Mon, 24 May 2021 20:23:51 -0500	[thread overview]
Message-ID: <60ac51a7ecf74_1f8f720843@natae.notmuch> (raw)
In-Reply-To: <>

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

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


Felipe Contreras

  reply	other threads:[~2021-05-25  1:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20  9:51 [Bug] git-credential-netrc.perl is not built and is not available in `exec-path` Siavash
2021-05-20 20:41 ` Jonathan Nieder
2021-05-21 10:26   ` Siavash
2021-05-21  1:55 ` brian m. carlson
2021-05-21 10:04   ` Jeff King
2021-05-21 22:27     ` brian m. carlson
2021-05-23 19:57       ` Jeff King
2021-05-24  3:01         ` Felipe Contreras
2021-05-24 10:05           ` Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]") Ævar Arnfjörð Bjarmason
2021-05-24 17:21             ` Felipe Contreras
2021-05-24 23:18               ` Ævar Arnfjörð Bjarmason
2021-05-25  1:23                 ` Felipe Contreras [this message]
2021-05-25  6:51             ` Junio C Hamano
2021-05-25  7:31               ` Bagas Sanjaya
2021-05-25  9:05                 ` Felipe Contreras
2021-05-25 10:35               ` Felipe Contreras
2021-05-21 10:06 ` [Bug] git-credential-netrc.perl is not built and is not available in `exec-path` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60ac51a7ecf74_1f8f720843@natae.notmuch \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).