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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 24, 2021, 10:05 UTC
Message-ID: <87o8d0o2or.fsf@evledraar.gmail.com>
In-Reply-To: <60ab17018efee_1691c20832@natae.notmuch>

On Sun, May 23 2021, Felipe Contreras wrote:

Show 13 quoted lines

> 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:
> https://lore.kernel.org/git/1399607587-14127-1-git-send-email-felipe.contreras@gmail.com/

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, check-builtins.sh 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.