On Wed, Mar 29, 2023 at 9:15 PM Junio C Hamano [off-list ref] wrote:

If the native mode didn't impose too much burden on our developers'
to maintain, it would have been nicer, but judging from the contents
of these patches, I am afraid that it falls on the other side of the
line.

There is zero burden to maintain.

What burden did this fix specific for ksh93 cause to "our developers"
0e418e568f (t0005: work around strange $? in ksh when program
terminated by a signal, 2010-07-09)?

--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh

@@ -13,6 +13,7 @@ test_expect_success 'sigchain works' '
        test-sigchain >actual
        case "$?" in
        143) true ;; # POSIX w/ SIGTERM=15
+       271) true ;; # ksh w/ SIGTERM=15
          3) true ;; # Windows
          *) false ;;
        esac &&

This patch was applied once and forgotten about for 6 six years until
one developer refactored the code in 9b67c9942e (tests: factor
portable signal check out of t0005, 2016-06-30).

"Our developers" did not have to care about code that affected only
one shell. Not since 2010, not since 2016, not even today.

Even the original author admitted he didn't understand how this code
truly interacted in other situations [1]:

Frankly, I don't know how bash's 'kill -TERM' and a Windows program
interact.  I've avoided this topic like the plague so far.

It's not true that applying patches to fix a situation for a specific
shell causes a hypothetical burden to our developers to magically
appear.

In reality the patch is applied once and forgotten about it until a)
another developer stumbles upon a similar problem, or b) another
developer stumbles upon that specific code.

No developer cared about 0e418e568f being applied. It fixed the
situation for one shell, it didn't affect other shells negatively, and
that's all anyone needed to know.

[1] https://lore.kernel.org/git/576DA6FB.1050108@kdbg.org (local)

-- 
Felipe Contreras