{"thread":{"id":"64392","subject":"[ANNOUNCE] Git v2.51.2","startedAt":"2025-10-27T15:56:50Z","lastAt":"2025-10-31T14:10:05Z","messageCount":18,"participants":["Junio C Hamano","rsbecker@nexbridge.com","SZEDER Gábor","Jeff King","D. Ben Knoble","Kristoffer Haugsbakk","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"529739","messageId":"xmqqo6psjq2n.fsf@gitster.g","threadId":"64392","inReplyTo":null,"subject":"[ANNOUNCE] Git v2.51.2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-27T15:56:48Z","receivedAt":"2025-10-27T15:56:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The latest maintenance release Git v2.51.2 is now available at\nthe usual places.\n\nThe tarballs are found at:\n\n    https://www.kernel.org/pub/software/scm/git/\n\nThe following public repositories all have a copy of the 'v2.51.2'\ntag and the 'maint' branch that the tag points at:\n\n  url = https://git.kernel.org/pub/scm/git/git\n  url = https://kernel.googlesource.com/pub/scm/git/git\n  url = git://repo.or.cz/alt-git.git\n  url = https://github.com/gitster/git\n\n----------------------------------------------------------------\n\nGit 2.51.2 Release Notes\n========================\n\nIn addition to fixes for an unfortunate regression introduced in Git\n2.51.1 that caused \"git diff --quiet -w\" to be not so quiet when there\nare additions, deletions and conflicts, this maintenance release merges\nmore fixes/improvements that have landed on the master front, primarily\nto make the CI part of the system a bit more robust.\n\n\nFixes since Git 2.51.1\n----------------------\n\n * Recently we attempted to improve \"git diff -w --quiet\" and friends\n   to handle cases where patch output would be suppressed, but it\n   introduced a bug that emits unnecessary output, which has been\n   corrected.\n\n * The code to squelch output from \"git diff -w --name-status\"\n   etc. for paths that \"git diff -w -p\" would have stayed silent\n   leaked output from dry-run patch generation, which has been\n   corrected.\n\n * Windows \"real-time monitoring\" interferes with the execution of\n   tests and affects negatively in both correctness and performance,\n   which has been disabled in Gitlab CI.\n\n * An earlier addition to \"git diff --no-index A B\" to limit the\n   output with pathspec after the two directories misbehaved when\n   these directories were given with a trailing slash, which has been\n   corrected.\n\n * The \"--short\" option of \"git status\" that meant output for humans\n   and \"-z\" option to show NUL delimited output format did not mix\n   well, and colored some but not all things.  The command has been\n   updated to color all elements consistently in such a case.\n\n * Unicode width table update.\n\n * Recent OpenSSH creates the Unix domain socket to communicate with\n   ssh-agent under $HOME instead of /tmp, which causes our test to\n   fail doe to overly long pathname in our test environment, which has\n   been worked around by using \"ssh-agent -T\".\n\nAlso contains various documentation updates, code cleanups and minor fixups.\n\n----------------------------------------------------------------\n\nChanges since v2.51.1 are as follows:\n\nJacob Keller (1):\n      diff --no-index: fix logic for paths ending in '/'\n\nJeff King (2):\n      diff: restore redirection to /dev/null for diff_from_contents\n      status: make coloring of \"-z --short\" consistent\n\nJohannes Schindelin (5):\n      refs: forbid clang to complain about unreachable code\n      build(deps): bump actions/download-artifact from 4 to 5\n      build(deps): bump actions/checkout from 4 to 5\n      build(deps): bump actions/setup-python from 5 to 6\n      build(deps): bump actions/github-script from 7 to 8\n\nJunio C Hamano (2):\n      diff: make sure the other caller of diff_flush_patch_quietly() is silent\n      Git 2.51.2\n\nKristoffer Haugsbakk (1):\n      doc: fix accidental literal blocks\n\nPatrick Steinhardt (2):\n      gitlab-ci: disable realtime monitoring to unbreak Windows jobs\n      t7528: work around ETOOMANY in OpenSSH 10.1 and newer\n\nSolly (1):\n      t2401: update path checks using test_path helpers\n\nTorsten Bögershausen (1):\n      unicode: update the width tables to Unicode 17\n\n"},{"id":"529804","messageId":"000d01dc4831$ff049500$fd0dbf00$@nexbridge.com","threadId":"64392","inReplyTo":"xmqqo6psjq2n.fsf@gitster.g","subject":"[BUGS] Git v2.51.2 on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-28T17:40:42Z","receivedAt":"2025-10-28T17:40:55Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"I have found new defects on 2.51.2 that were not present in 2.51.1 when building with OpenSSL 3.5 (probably unrelated).\n\nMany failures in t7900 resulting from the use of test_subcommand ! as seen below. This is run in bash 5.0.18:\n\n+ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n+ 0< run-no-auto.txt\n{\"event\":\"child_start\",\"sid\":\"20251028T172435.690328Z-H36b1c598-P7b00002d\",\"thread\":\"main\",\"time\":\"2025-10-28T17:24:35.879833Z\",\"file\":\"/home/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c\",\"line\":740,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n+ test_subcommand ! git gc --auto --quiet --no-detach --skip-foreground-tasks\n+ 0< run-auto.txt\ntest_subcommand[5]: test: argument expected\n\nRegards,\nRandall\n\n"},{"id":"529905","messageId":"aQKVByfUdYHSEcDz@szeder.dev","threadId":"64392","inReplyTo":"000d01dc4831$ff049500$fd0dbf00$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2025-10-29T22:28:23Z","receivedAt":"2025-10-29T22:28:26Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:\n> I have found new defects on 2.51.2 that were not present in 2.51.1 when building with OpenSSL 3.5 (probably unrelated).\n> \n> Many failures in t7900 resulting from the use of test_subcommand ! as seen below. This is run in bash 5.0.18:\n> \n> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n> + 0< run-no-auto.txt\n> {\"event\":\"child_start\",\"sid\":\"20251028T172435.690328Z-H36b1c598-P7b00002d\",\"thread\":\"main\",\"time\":\"2025-10-28T17:24:35.879833Z\",\"file\":\"/home/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c\",\"line\":740,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n> + test_subcommand ! git gc --auto --quiet --no-detach --skip-foreground-tasks\n> + 0< run-auto.txt\n> test_subcommand[5]: test: argument expected\n\nThis is a strange trace output, as it includes file descriptor\nredirections, but lacks the trace of commands executed in\ntest_subcommands.  This trace doesn't look like it's coming from Bash.\n\n"},{"id":"529907","messageId":"000201dc4925$2cdbc450$86934cf0$@nexbridge.com","threadId":"64392","inReplyTo":"aQKVByfUdYHSEcDz@szeder.dev","subject":"RE: [BUGS] Git v2.51.2 on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-29T22:41:27Z","receivedAt":"2025-10-29T22:41:40Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 29, 2025 6:28 PM, SZEDER Gábor wrote:\n>On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:\n>> I have found new defects on 2.51.2 that were not present in 2.51.1 when building\n>with OpenSSL 3.5 (probably unrelated).\n>>\n>> Many failures in t7900 resulting from the use of test_subcommand ! as seen\n>below. This is run in bash 5.0.18:\n>>\n>> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n>> + 0< run-no-auto.txt\n>> {\"event\":\"child_start\",\"sid\":\"20251028T172435.690328Z-H36b1c598-P7b000\n>> 02d\",\"thread\":\"main\",\"time\":\"2025-10-28T17:24:35.879833Z\",\"file\":\"/hom\n>> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c\",\"line\":7\n>> 40,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\"\n>> ,\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n>> + test_subcommand ! git gc --auto --quiet --no-detach\n>> + --skip-foreground-tasks 0< run-auto.txt\n>> test_subcommand[5]: test: argument expected\n>\n>This is a strange trace output, as it includes file descriptor redirections, but lacks the\n>trace of commands executed in test_subcommands.  This trace doesn't look like it's\n>coming from Bash.\n\nThe test_subcommand[5]: test: argument expect is coming from bash. I cannot see how\nit is coming from anywhere else. The test was run with -x but snipped. Reference to\ntest_subcommand ! git... fails exactly the same way. Is there something else I can provide?\n\n"},{"id":"529913","messageId":"aQKgxfZ9WQjyrhpa@szeder.dev","threadId":"64392","inReplyTo":"000201dc4925$2cdbc450$86934cf0$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2025-10-29T23:18:29Z","receivedAt":"2025-10-29T23:18:33Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Wed, Oct 29, 2025 at 06:41:27PM -0400, rsbecker@nexbridge.com wrote:\n> On October 29, 2025 6:28 PM, SZEDER Gábor wrote:\n> >On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:\n> >> I have found new defects on 2.51.2 that were not present in 2.51.1 when building\n> >with OpenSSL 3.5 (probably unrelated).\n> >>\n> >> Many failures in t7900 resulting from the use of test_subcommand ! as seen\n> >below. This is run in bash 5.0.18:\n> >>\n> >> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n> >> + 0< run-no-auto.txt\n> >> {\"event\":\"child_start\",\"sid\":\"20251028T172435.690328Z-H36b1c598-P7b000\n> >> 02d\",\"thread\":\"main\",\"time\":\"2025-10-28T17:24:35.879833Z\",\"file\":\"/hom\n> >> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c\",\"line\":7\n> >> 40,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\"\n> >> ,\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n> >> + test_subcommand ! git gc --auto --quiet --no-detach\n> >> + --skip-foreground-tasks 0< run-auto.txt\n> >> test_subcommand[5]: test: argument expected\n> >\n> >This is a strange trace output, as it includes file descriptor redirections, but lacks the\n> >trace of commands executed in test_subcommands.  This trace doesn't look like it's\n> >coming from Bash.\n> \n> The test_subcommand[5]: test: argument expect is coming from bash. I cannot see how\n> it is coming from anywhere else. The test was run with -x but snipped. Reference to\n> test_subcommand ! git... fails exactly the same way. Is there something else I can provide?\n\nThe -x trace from Bash doesn't include file descriptor redirections,\nbut includes the commands executed in test_subcommand, and the number\nof '+' characters at the beginning of each trace line indicates the\nnumber of subshells, so when the test is really run by Bash the trace\nfrom a test_subcommand invocation looks like this:\n\n  ++ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n  ++ local negate=\n  ++ test git = '!'\n  +++ printf '\"%s\",' git gc --quiet --no-detach --skip-foreground-tasks\n  ++ local 'expr=\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\",'\n  ++ expr='\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"'\n  ++ test -n ''\n  ++ grep '\\[\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"\\]'\n  {\"event\":\"child_start\",\"sid\":\"20251029T230304.507599Z-H3fb05a16-P001a33ae\",\"thread\":\"main\",\"time\":\"2025-10-29T23:03:04.512913Z\",\"file\":\"run-command.c\",\"line\":740,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n  ++ test_subcommand '!' git gc --auto --quiet --no-detach --skip-foreground-tasks\n  ++ local negate=\n\nSince the trace you showed doesn't look like this I still doubt that\nit came from Bash.\n\n"},{"id":"529916","messageId":"000701dc4933$9f79c670$de6d5350$@nexbridge.com","threadId":"64392","inReplyTo":"aQKgxfZ9WQjyrhpa@szeder.dev","subject":"RE: [BUGS] Git v2.51.2 on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-30T00:24:52Z","receivedAt":"2025-10-30T00:25:00Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 29, 2025 7:18 PM, SZEDER Gábor wrote:\n>On Wed, Oct 29, 2025 at 06:41:27PM -0400, rsbecker@nexbridge.com wrote:\n>> On October 29, 2025 6:28 PM, SZEDER Gábor wrote:\n>> >On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:\n>> >> I have found new defects on 2.51.2 that were not present in 2.51.1\n>> >> when building\n>> >with OpenSSL 3.5 (probably unrelated).\n>> >>\n>> >> Many failures in t7900 resulting from the use of test_subcommand !\n>> >> as seen\n>> >below. This is run in bash 5.0.18:\n>> >>\n>> >> + test_subcommand git gc --quiet --no-detach\n>> >> + --skip-foreground-tasks 0< run-no-auto.txt\n>> >> {\"event\":\"child_start\",\"sid\":\"20251028T172435.690328Z-H36b1c598-P7b\n>> >> 000\n>> >> 02d\",\"thread\":\"main\",\"time\":\"2025-10-28T17:24:35.879833Z\",\"file\":\"/\n>> >> hom\n>> >> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c\",\"line\n>> >> \":7\n>> >> 40,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\"gc\"\n>> >> ,\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n>> >> + test_subcommand ! git gc --auto --quiet --no-detach\n>> >> + --skip-foreground-tasks 0< run-auto.txt\n>> >> test_subcommand[5]: test: argument expected\n>> >\n>> >This is a strange trace output, as it includes file descriptor\n>> >redirections, but lacks the trace of commands executed in\n>> >test_subcommands.  This trace doesn't look like it's coming from Bash.\n>>\n>> The test_subcommand[5]: test: argument expect is coming from bash. I\n>> cannot see how it is coming from anywhere else. The test was run with\n>> -x but snipped. Reference to test_subcommand ! git... fails exactly the same way.\n>Is there something else I can provide?\n>\n>The -x trace from Bash doesn't include file descriptor redirections, but includes the\n>commands executed in test_subcommand, and the number of '+' characters at the\n>beginning of each trace line indicates the number of subshells, so when the test is\n>really run by Bash the trace from a test_subcommand invocation looks like this:\n>\n>  ++ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks\n>  ++ local negate=\n>  ++ test git = '!'\n>  +++ printf '\"%s\",' git gc --quiet --no-detach --skip-foreground-tasks\n>  ++ local 'expr=\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\",'\n>  ++ expr='\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"'\n>  ++ test -n ''\n>  ++ grep '\\[\"git\",\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"\\]'\n>  {\"event\":\"child_start\",\"sid\":\"20251029T230304.507599Z-H3fb05a16-\n>P001a33ae\",\"thread\":\"main\",\"time\":\"2025-10-29T23:03:04.512913Z\",\"file\":\"run-\n>command.c\",\"line\":740,\"child_id\":2,\"child_class\":\"?\",\"use_shell\":false,\"argv\":[\"git\",\n>\"gc\",\"--quiet\",\"--no-detach\",\"--skip-foreground-tasks\"]}\n>  ++ test_subcommand '!' git gc --auto --quiet --no-detach --skip-foreground-tasks\n>  ++ local negate=\n>\n>Since the trace you showed doesn't look like this I still doubt that it came from Bash.\n\nWhat appears to be happening is that the Make environment is only using SHELL=/bin/bash\nfor the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh\nas specified, which uses ksh, not bash, which is the trace above. When I run the individual\ntests with bash, the error reported goes away. The problem is, with my version of Gnu Make,\n4.1.2, the SHELL variable is only being replaced for the command processing of each\nrecipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,\nand fails out. This means that I have to remember to manually run each test that fails with\nbash instead of the default. It is frustrating and now adds hours to my manual evaluation\nof the CI/CD results.\n\nThe trace above is from sh, not bash because of this.\n\nWith Frustration,\nRandall\n\n"},{"id":"529919","messageId":"20251030025301.GA1266932@coredump.intra.peff.net","threadId":"64392","inReplyTo":"000701dc4933$9f79c670$de6d5350$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-10-30T02:53:01Z","receivedAt":"2025-10-30T02:53:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 29, 2025 at 08:24:52PM -0400, rsbecker@nexbridge.com wrote:\n\n> What appears to be happening is that the Make environment is only using SHELL=/bin/bash\n> for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh\n> as specified, which uses ksh, not bash, which is the trace above. When I run the individual\n> tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,\n> 4.1.2, the SHELL variable is only being replaced for the command processing of each\n> recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,\n> and fails out. This means that I have to remember to manually run each test that fails with\n> bash instead of the default. It is frustrating and now adds hours to my manual evaluation\n> of the CI/CD results.\n> \n> The trace above is from sh, not bash because of this.\n\nDoes \"make TEST_SHELL_PATH=/bin/bash\" work?\n\nThe default there is $(SHELL_PATH), which is distinct again from\n$(SHELL). The former is a Git-ism for the shell we replace in #! lines\nand invoke from within C programs, and the latter is a make-ism for how\nto run make recipes. If your /bin/sh isn't fully functional you might\nwant to be setting SHELL_PATH, too.\n\n-Peff\n"},{"id":"529965","messageId":"CALnO6CAYmtDmfk36nX6TCCaV2c=8J0BXv9eN+L=j1PU=gPmJUQ@mail.gmail.com","threadId":"64392","inReplyTo":"000701dc4933$9f79c670$de6d5350$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-10-30T13:52:34Z","receivedAt":"2025-10-30T13:52:48Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:\n>\n> What appears to be happening is that the Make environment is only using SHELL=/bin/bash\n> for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh\n> as specified, which uses ksh, not bash, which is the trace above. When I run the individual\n> tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,\n> 4.1.2, the SHELL variable is only being replaced for the command processing of each\n> recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,\n> and fails out. This means that I have to remember to manually run each test that fails with\n> bash instead of the default. It is frustrating and now adds hours to my manual evaluation\n> of the CI/CD results.\n>\n> The trace above is from sh, not bash because of this.\n>\n> With Frustration,\n> Randall\n\nIs this the only ksh-induced failure? And if so, what is inducing the\nfailure—is it something the test library can work around, or is the\nsystem {k,}sh not behaving portably here?\n\nMy preference would be towards making your setup \"just work\" assuming\nthere's not a clear contradiction of portable standards somewhere.\n\n-- \nD. Ben Knoble\n"},{"id":"529969","messageId":"006e01dc49ad$d12f9a80$738ecf80$@nexbridge.com","threadId":"64392","inReplyTo":"CALnO6CAYmtDmfk36nX6TCCaV2c=8J0BXv9eN+L=j1PU=gPmJUQ@mail.gmail.com","subject":"RE: [BUGS] Git v2.51.2 on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-30T14:59:34Z","receivedAt":"2025-10-30T14:59:42Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 30, 2025 9:53 AM, D. Ben Knoble wrote:\n>On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:\n>>\n>> What appears to be happening is that the Make environment is only\n>> using SHELL=/bin/bash for the outer processing but not the inner\n>> #!/bin/sh of t7900. The system is using /bin/sh as specified, which\n>> uses ksh, not bash, which is the trace above. When I run the\n>> individual tests with bash, the error reported goes away. The problem\n>> is, with my version of Gnu Make, 4.1.2, the SHELL variable is only\n>> being replaced for the command processing of each recipe. Once the\n>> system loader sees the shebang of #!/bin/sh, /bin/sh is used as\n>> requested, and fails out. This means that I have to remember to manually run\n>each test that fails with bash instead of the default. It is frustrating and now adds\n>hours to my manual evaluation of the CI/CD results.\n>>\n>> The trace above is from sh, not bash because of this.\n>>\n>> With Frustration,\n>> Randall\n>\n>Is this the only ksh-induced failure? And if so, what is inducing the failure—is it\n>something the test library can work around, or is the system {k,}sh not behaving\n>portably here?\n>\n>My preference would be towards making your setup \"just work\" assuming there's\n>not a clear contradiction of portable standards somewhere.\n\nI think there were other ksh issues, mostly the SHELL= setting in make. I will report\nothers on a per test case basis when they come. The SHELL_PATH= definitely is\nusing bash, so that fix suggested by Peff is working out nicely.\n\nRegards,\nRandall\n\n"},{"id":"529971","messageId":"729f9bbf-b75b-4161-b8aa-505ff906bb8a@app.fastmail.com","threadId":"64392","inReplyTo":"000d01dc4831$ff049500$fd0dbf00$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-30T15:15:27Z","receivedAt":"2025-10-30T15:15:50Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n> I have found new defects on 2.51.2 that were not present in 2.51.1 when\n> building with OpenSSL 3.5 (probably unrelated).\n>\n> Many failures in t7900 resulting from the use of test_subcommand ! as\n> seen below. This is run in bash 5.0.18:\n>\n>[snip]\n\nWould it make sense for maintenance releases to have a small release\ncandidate pre-release?  Both of these maintenance releases have had\nissues.\n"},{"id":"529975","messageId":"007501dc49b6$aacd9eb0$0068dc10$@nexbridge.com","threadId":"64392","inReplyTo":"729f9bbf-b75b-4161-b8aa-505ff906bb8a@app.fastmail.com","subject":"RE: [BUGS] Git v2.51.2 on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-30T16:02:55Z","receivedAt":"2025-10-30T16:03:04Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 30, 2025 11:15 AM, Kristoffer Haugsbakk wrote:\n>On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>> I have found new defects on 2.51.2 that were not present in 2.51.1\n>> when building with OpenSSL 3.5 (probably unrelated).\n>>\n>> Many failures in t7900 resulting from the use of test_subcommand ! as\n>> seen below. This is run in bash 5.0.18:\n>>\n>>[snip]\n>\n>Would it make sense for maintenance releases to have a small release\ncandidate pre-\n>release?  Both of these maintenance releases have had issues.\n\nInteresting question. I would personally prefer that maintenance releases\nwould be\nfixes only, rather than new functionality or introduction of new\ndependencies or\nconstructs that might break the main release. If there is something\nsignificant done,\nit should be in a main release, with a release candidate. I think we should\nbe cutting\ndown what is in maintenance releases so that release candidates are not\nrequired.\n\nObviously, if there is a CVE and we need a maintenance release to fix it,\nand the CVE\nhas breaking changes, we have an issue - and if significant enough, then\nyes, a\nrelease candidate should be done.\n\nJust my opinion,\nRandall\n\n"},{"id":"529983","messageId":"xmqqecqk5g7r.fsf@gitster.g","threadId":"64392","inReplyTo":"729f9bbf-b75b-4161-b8aa-505ff906bb8a@app.fastmail.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-10-30T19:42:32Z","receivedAt":"2025-10-30T19:42:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n\n> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>> I have found new defects on 2.51.2 that were not present in 2.51.1 when\n>> building with OpenSSL 3.5 (probably unrelated).\n>>\n>> Many failures in t7900 resulting from the use of test_subcommand ! as\n>> seen below. This is run in bash 5.0.18:\n>>\n>>[snip]\n>\n> Would it make sense for maintenance releases to have a small release\n> candidate pre-release?  Both of these maintenance releases have had\n> issues.\n\nWell, that is usually called \"the tip of 'master'\".  Has NonStop\nbeen having issues with the tip of 'master'?  For how long?  Why\nhaven't we heard about it at all?  After things are merged there\n(which requires them to be cooking in 'next'---oh, has NonStop been\nhaving issues with 'next'?  For how long?), only fixes are chosen\nand merged to 'maint' to be the next maintenance release.  I doubt\nany pre-release on 'maint' has much value in that anybody who are\nnot testing the tip of 'master' would not be testing it either.\n\n"},{"id":"529985","messageId":"3dad5cb9-976b-4e60-9e6e-05c12c7d9f2d@app.fastmail.com","threadId":"64392","inReplyTo":"xmqqecqk5g7r.fsf@gitster.g","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-10-30T20:25:42Z","receivedAt":"2025-10-30T20:26:04Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:\n> \"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n>\n>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>>>[snip]\n>>\n>> Would it make sense for maintenance releases to have a small release\n>> candidate pre-release?  Both of these maintenance releases have had\n>> issues.\n>\n> Well, that is usually called \"the tip of 'master'\".  Has NonStop\n> been having issues with the tip of 'master'?  For how long?  Why\n> haven't we heard about it at all?  After things are merged there\n> (which requires them to be cooking in 'next'---oh, has NonStop been\n> having issues with 'next'?  For how long?), only fixes are chosen\n> and merged to 'maint' to be the next maintenance release.\n> ...\n> I doubt any pre-release on 'maint' has much value in that anybody who\n> are not testing the tip of 'master' would not be testing it either.\n\nYou are probably 99.9% likely to be correct.\n"},{"id":"529987","messageId":"aQPXSyyHWz8hKaJe@fruit.crustytoothpaste.net","threadId":"64392","inReplyTo":"CALnO6CAYmtDmfk36nX6TCCaV2c=8J0BXv9eN+L=j1PU=gPmJUQ@mail.gmail.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-10-30T21:23:23Z","receivedAt":"2025-10-30T21:23:32Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-10-30 at 13:52:34, D. Ben Knoble wrote:\n> On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:\n> >\n> > What appears to be happening is that the Make environment is only using SHELL=/bin/bash\n> > for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh\n> > as specified, which uses ksh, not bash, which is the trace above. When I run the individual\n> > tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,\n> > 4.1.2, the SHELL variable is only being replaced for the command processing of each\n> > recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,\n> > and fails out. This means that I have to remember to manually run each test that fails with\n> > bash instead of the default. It is frustrating and now adds hours to my manual evaluation\n> > of the CI/CD results.\n> >\n> > The trace above is from sh, not bash because of this.\n> >\n> > With Frustration,\n> > Randall\n> \n> Is this the only ksh-induced failure? And if so, what is inducing the\n> failure—is it something the test library can work around, or is the\n> system {k,}sh not behaving portably here?\n\nWe know that AT&T ksh (ksh93) doesn't work for Git because we require\n`local` and AT&T ksh doesn't offer that.  Other ksh implementations,\nsuch as pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh),\nksh88, and various others, do in fact work just fine because they\nsupport `local`.  The `test_subcommand` function does use `local`,\nso that may explain why things aren't working.\n\nksh (and zsh in zsh mode, but not in sh mode[0]) also run the last command\nin a pipeline in the main shell instead of a subshell.  That may also be\na source of incompatibility.\n\nIt may also be failing to work for other reasons as well, though.\n\n[0] To be clear, zsh has never successfully run our testsuite in zsh\nmode, but it should mostly work in sh mode.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"529991","messageId":"009f01dc49e6$98c5ae30$ca510a90$@nexbridge.com","threadId":"64392","inReplyTo":"3dad5cb9-976b-4e60-9e6e-05c12c7d9f2d@app.fastmail.com","subject":"RE: [BUGS] Git v2.51.2 on NonStop5","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-30T21:46:01Z","receivedAt":"2025-10-30T21:46:10Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:\n>On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:\n>> \"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n>>\n>>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>>>>[snip]\n>>>\n>>> Would it make sense for maintenance releases to have a small release\n>>> candidate pre-release?  Both of these maintenance releases have had\n>>> issues.\n>>\n>> Well, that is usually called \"the tip of 'master'\".  Has NonStop been\n>> having issues with the tip of 'master'?  For how long?  Why haven't we\n>> heard about it at all?  After things are merged there (which requires\n>> them to be cooking in 'next'---oh, has NonStop been having issues with\n>> 'next'?  For how long?), only fixes are chosen and merged to 'maint'\n>> to be the next maintenance release.\n>> ...\n>> I doubt any pre-release on 'maint' has much value in that anybody who\n>> are not testing the tip of 'master' would not be testing it either.\n>\n>You are probably 99.9% likely to be correct.\n\nWe tried setting up a CI/CD process for git on NonStop. The problem is that\nwe use Jenkins, which gets triggered each time a change is made on a branch.\nThe actual difficulty is that a single run takes more than a day. Once the\ncommitter adds each commit to a branch, we end up with a queue that is\n2-3 weeks long, so end up not running a continuous process. Instead, we\nrun about 1 a week, which should catch things. The difficulty is with the\nlatest release is that 2.25.2 came out before our cycle and the breaks were\nin there because of changes to one test that just did not end up dequeuing\nin time. NonStop is building and testing fine now after Peff's suggestion on\nSHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this\nissue with our inadvertent use of ksh to run each test script.\n\n"},{"id":"529994","messageId":"aQPnDrsKLsLpaxgI@szeder.dev","threadId":"64392","inReplyTo":"009f01dc49e6$98c5ae30$ca510a90$@nexbridge.com","subject":"Re: [BUGS] Git v2.51.2 on NonStop5","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2025-10-30T22:30:38Z","receivedAt":"2025-10-30T22:30:43Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote:\n> On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:\n> >On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:\n> >> \"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n> >>\n> >>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n> >>>>[snip]\n> >>>\n> >>> Would it make sense for maintenance releases to have a small release\n> >>> candidate pre-release?  Both of these maintenance releases have had\n> >>> issues.\n> >>\n> >> Well, that is usually called \"the tip of 'master'\".  Has NonStop been\n> >> having issues with the tip of 'master'?  For how long?  Why haven't we\n> >> heard about it at all?  After things are merged there (which requires\n> >> them to be cooking in 'next'---oh, has NonStop been having issues with\n> >> 'next'?  For how long?), only fixes are chosen and merged to 'maint'\n> >> to be the next maintenance release.\n> >> ...\n> >> I doubt any pre-release on 'maint' has much value in that anybody who\n> >> are not testing the tip of 'master' would not be testing it either.\n> >\n> >You are probably 99.9% likely to be correct.\n> \n> We tried setting up a CI/CD process for git on NonStop. The problem is that\n> we use Jenkins, which gets triggered each time a change is made on a branch.\n> The actual difficulty is that a single run takes more than a day. Once the\n> committer adds each commit to a branch, we end up with a queue that is\n> 2-3 weeks long, so end up not running a continuous process. Instead, we\n> run about 1 a week, which should catch things. The difficulty is with the\n> latest release is that 2.25.2 came out before our cycle and the breaks were\n> in there because of changes to one test that just did not end up dequeuing\n> in time. NonStop is building and testing fine now after Peff's suggestion on\n> SHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this\n> issue with our inadvertent use of ksh to run each test script.\n\nNeither the test library nor t7900 changed in the last two maintenance\nreleases:\n\n  $ git rev-list --count v2.51.0..v2.51.2 -- t/test-lib.sh t/test-lib-functions.sh t/t7900-maintenance.sh\n  0\n\n"},{"id":"529996","messageId":"00c401dc4a02$14ae4eb0$3e0aec10$@nexbridge.com","threadId":"64392","inReplyTo":"aQPnDrsKLsLpaxgI@szeder.dev","subject":"RE: [BUGS] Git v2.51.2 on NonStop5","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-31T01:02:45Z","receivedAt":"2025-10-31T01:03:01Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 30, 2025 6:31 PM, SZEDER Gábor wrote:\n>On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote:\n>> On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:\n>> >On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:\n>> >> \"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n>> >>\n>> >>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>> >>>>[snip]\n>> >>>\n>> >>> Would it make sense for maintenance releases to have a small\n>> >>> release candidate pre-release?  Both of these maintenance releases\n>> >>> have had issues.\n>> >>\n>> >> Well, that is usually called \"the tip of 'master'\".  Has NonStop\n>> >> been having issues with the tip of 'master'?  For how long?  Why\n>> >> haven't we heard about it at all?  After things are merged there\n>> >> (which requires them to be cooking in 'next'---oh, has NonStop been\n>> >> having issues with 'next'?  For how long?), only fixes are chosen and merged to\n>'maint'\n>> >> to be the next maintenance release.\n>> >> ...\n>> >> I doubt any pre-release on 'maint' has much value in that anybody\n>> >> who are not testing the tip of 'master' would not be testing it either.\n>> >\n>> >You are probably 99.9% likely to be correct.\n>>\n>> We tried setting up a CI/CD process for git on NonStop. The problem is\n>> that we use Jenkins, which gets triggered each time a change is made on a branch.\n>> The actual difficulty is that a single run takes more than a day. Once\n>> the committer adds each commit to a branch, we end up with a queue\n>> that is\n>> 2-3 weeks long, so end up not running a continuous process. Instead,\n>> we run about 1 a week, which should catch things. The difficulty is\n>> with the latest release is that 2.25.2 came out before our cycle and\n>> the breaks were in there because of changes to one test that just did\n>> not end up dequeuing in time. NonStop is building and testing fine now\n>> after Peff's suggestion on SHELL_PATH, but that was only apparent at\n>> 2.52.2. 2.51.1 did not have this issue with our inadvertent use of ksh to run each\n>test script.\n>\n>Neither the test library nor t7900 changed in the last two maintenance\n>releases:\n>\n>  $ git rev-list --count v2.51.0..v2.51.2 -- t/test-lib.sh t/test-lib-functions.sh\n>t/t7900-maintenance.sh\n>  0\n\nHonestly, I do not know. I am just reporting my experience from my own\nCI/CD system. All builds are from scratch. Given that I am now using bash,\nthe situation is resolved as far as I am concerned. If the team wants me to\ntry to do a bisect, I can, but it will take weeks to do this based on how long\nthe compile/test cycles are.\n\n"},{"id":"530028","messageId":"010001dc4a70$0c7d67d0$25783770$@nexbridge.com","threadId":"64392","inReplyTo":"009f01dc49e6$98c5ae30$ca510a90$@nexbridge.com","subject":"RE: [BUGS] Git v2.51.2 on NonStop5","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-10-31T14:09:56Z","receivedAt":"2025-10-31T14:10:05Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On October 30, 2025 5:46 PM, I wrote:\n>To: 'Kristoffer Haugsbakk' <kristofferhaugsbakk@fastmail.com>; 'Junio C\nHamano'\n><gitster@pobox.com>\n>Cc: git@vger.kernel.org\n>Subject: RE: [BUGS] Git v2.51.2 on NonStop5\n>\n>On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:\n>>On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:\n>>> \"Kristoffer Haugsbakk\" <kristofferhaugsbakk@fastmail.com> writes:\n>>>\n>>>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:\n>>>>>[snip]\n>>>>\n>>>> Would it make sense for maintenance releases to have a small release\n>>>> candidate pre-release?  Both of these maintenance releases have had\n>>>> issues.\n>>>\n>>> Well, that is usually called \"the tip of 'master'\".  Has NonStop been\n>>> having issues with the tip of 'master'?  For how long?  Why haven't we\n>>> heard about it at all?  After things are merged there (which requires\n>>> them to be cooking in 'next'---oh, has NonStop been having issues with\n>>> 'next'?  For how long?), only fixes are chosen and merged to 'maint'\n>>> to be the next maintenance release.\n>>> ...\n>>> I doubt any pre-release on 'maint' has much value in that anybody who\n>>> are not testing the tip of 'master' would not be testing it either.\n>>\n>>You are probably 99.9% likely to be correct.\n>\n>We tried setting up a CI/CD process for git on NonStop. The problem is that\n>we use Jenkins, which gets triggered each time a change is made on a\nbranch.\n>The actual difficulty is that a single run takes more than a day. Once the\n>committer adds each commit to a branch, we end up with a queue that is\n>2-3 weeks long, so end up not running a continuous process. Instead, we\n>run about 1 a week, which should catch things. The difficulty is with the\n>latest release is that 2.25.2 came out before our cycle and the breaks were\n>in there because of changes to one test that just did not end up dequeuing\n>in time. NonStop is building and testing fine now after Peff's suggestion\non\n>SHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this\n>issue with our inadvertent use of ksh to run each test script.\n\nThe current CI/CD run passed with only t9001 failing as expected. I am\nwondering whether we could add a switch like SENDMAIL=NoThanks. There\nis an object called sendmail on the box I am on, but it is not a compliant\nport - someone tried this decades ago.\n\n"}]}