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

On Sun, May 23 2021, Felipe Contreras wrote:

> Jeff King wrote:
>> I suspect that just opening a bug report against distro packages might
>> get some traction (especially if it comes with a patch to create the
>> extra package).
> I have tried that; do doesn't work. If git developers have $x in
> "contrib" it's for a reason.
>> I do wonder if packagers are hesitant to reach into
>> contrib/,
> Of course they are! The word "contrib" has an obvious meaning.

[Minor edit to the quoted text to inline the link]:

> This is precisely the reason why I tried to graduate
> "contrib/completion" out of "contrib" to no avail:

Seems like that patch just got no replies at the time. FWIW I'd very
much be for it and would encourage you to re-submit it.

I'm not sure s/shared/contrib/g is the best naming though, but maybe I'm
contributing to needless bikeshedding by mentioning that.

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.

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/* ?

For some of these names a general re-arrangement of contrib/* would be a
logical thing to follow, e.g. I think it would make sense to carve out
various ci/, contrib/coccinelle, Documentation/doc-diff, etc. and other "only for supporting git.git
development" or "only called by our own Makefile(s)" into some
consistently named pattern.

I'm also very much in favor of building and testing all of this software
by default, to the best of our ability. We've had some avoidable bitrot
e.g. in subtree and mw-to-git in the past, some of that is a pain to
test (e.g. requiring an installed MediaWiki), but we can usually
build/test some part of it (e.g. in that case, does it even compile as
Perl code?). In other cases we could compile/test things by default on
certain platforms if they're platform-specific.

  reply	other threads:[~2021-05-24 10:18 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           ` Ævar Arnfjörð Bjarmason [this message]
2021-05-24 17:21             ` Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]") Felipe Contreras
2021-05-24 23:18               ` Ævar Arnfjörð Bjarmason
2021-05-25  1:23                 ` Felipe Contreras
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 \ \ \ \ \ \ \ \

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