From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
Git Users <git@vger.kernel.org>
Subject: Re: [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH
Date: Sat, 17 Apr 2021 20:28:53 +0000 [thread overview]
Message-ID: <YHtFBeWxE2cFlShY@camp.crustytoothpaste.net> (raw)
In-Reply-To: <87r1j91427.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On 2021-04-17 at 12:36:00, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, Apr 17 2021, Bagas Sanjaya wrote:
>
> > On 17/04/21 15.43, Ævar Arnfjörð Bjarmason wrote:
> >> Since then the consensus changed to having no new such commands unless
> >> necessary, and existing ones have been actively migrated to C.
> >
> > What I implied that when we need to implement new commands, it must
> > be directly written in C (steeper learning curve and more tedious
> > than implemented in shell script), so I'm against this proposal.
>
> I updated the v2 of this to note that I'm not really proposing anything
> new, but just bringing the document in line with reality. For a long
> time now we've rejected any new non-C things being imported into the
> tree, unless those that fall under the "such as an importer to convert
> random-scm-X" language that's still retained in the CodingGuidelines.
>
> I think that even if you or someone else wanted to write a new thing in
> Perl or SH we'd want a new way of doing that now anyway,
> e.g. git-send-email.perl should really be a helper for a C program
> rather than a stand-alone thing.
I'm also kind of opposed to this change. For example, I plan on adding
a utility to fill in SHA-1 compatibility things for SHA-256 repos, and
that will be written in shell. The performance benefit of C here is
going to be minimal, especially considering the fact that people will be
running it literally at most once per repo, so I don't see a reason to
spend a lot of time writing C code.
I'm not of the opinion that we should never have shell or Perl code in
our project, nor does it intrinsically make sense to migrate everything
to C. Typically we've done that because it performs better, especially
on Windows, but there are many situations in which those are not major
considerations and shell or Perl can be a desirable approach.
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2021-04-17 20:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-17 8:43 [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH Ævar Arnfjörð Bjarmason
2021-04-17 8:53 ` Torsten Bögershausen
2021-04-17 12:17 ` Bagas Sanjaya
2021-04-17 12:36 ` Ævar Arnfjörð Bjarmason
2021-04-17 20:28 ` brian m. carlson [this message]
2021-04-17 21:37 ` Ævar Arnfjörð Bjarmason
2021-04-17 22:10 ` brian m. carlson
2021-04-17 12:31 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2021-04-17 22:01 ` [PATCH] " Junio C Hamano
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YHtFBeWxE2cFlShY@camp.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=avarab@gmail.com \
--cc=bagasdotme@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).