Re: [PATCH] CodingGuidelines: remove suggestion to write commands in Perl/SH

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 17, 2021, 22:01 UTC
Message-ID: <xmqqmttwbmfm.fsf@gitster.g>
In-Reply-To: <patch-1.1-83266f30b67-20210417T084346Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Remove a suggestion to write new commands in Perl or Shell to
> experiment. This advice was added in 6d0618a820a (Add
> Documentation/CodingGuidelines, 2007-11-08).

I think this needs to be rephrased to clarify that it is mainly to allow easier prototyping.

> Since then the consensus changed to having no new such commands unless
> necessary, and existing ones have been actively migrated to C.

Well, "unless necessary" is quite an interesting word here. There are trade-offs, and some things are not worth spending cycles to write in C than leaving quick hackability for developers.

Also existing ones getting migrated to C does nothing to support the implicit claim the above sentence makes, which is "writing the first version in C is recommended".

    If you are planning a new command, it may be easier to prototype
    by implementing it as a script, until you and others on the list
    can figure out what the semantics and end-user experience should
    be, instead of starting the initial version in C code.  Many Git
    commands started out as scripts and then later rewritten in C.

More importantly, we probably should stress that we've been very bad at maintaining plumbing to allow such quick experimentation. We should encourage (or even require) developers to make the feature they directly hacked into the Porcelain command available also to the plumbing layer, so that those who script with plumbing commands can also use it.

Show 8 quoted lines

> - - If you are planning a new command, consider writing it in shell
> -   or perl first, so that changes in semantics can be easily
> -   changed and discussed.  Many Git commands started out like
> -   that, and a few are still scripts.
> -
>   - Avoid introducing a new dependency into Git. This means you
>     usually should stay away from scripting languages not already
>     used in the Git core command set (unless your command is clearly