[ANNOUNCE] Git v2.51.2

[ANNOUNCE] Git v2.51.2

[Junio C Hamano]

The latest maintenance release Git v2.51.2 is now available at
the usual places.

The tarballs are found at:

    https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.51.2'
tag and the 'maint' branch that the tag points at:

  url = https://git.kernel.org/pub/scm/git/git
  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git

----------------------------------------------------------------

Git 2.51.2 Release Notes
========================

In addition to fixes for an unfortunate regression introduced in Git
2.51.1 that caused "git diff --quiet -w" to be not so quiet when there
are additions, deletions and conflicts, this maintenance release merges
more fixes/improvements that have landed on the master front, primarily
to make the CI part of the system a bit more robust.


Fixes since Git 2.51.1
----------------------

 * Recently we attempted to improve "git diff -w --quiet" and friends
   to handle cases where patch output would be suppressed, but it
   introduced a bug that emits unnecessary output, which has been
   corrected.

 * The code to squelch output from "git diff -w --name-status"
   etc. for paths that "git diff -w -p" would have stayed silent
   leaked output from dry-run patch generation, which has been
   corrected.

 * Windows "real-time monitoring" interferes with the execution of
   tests and affects negatively in both correctness and performance,
   which has been disabled in Gitlab CI.

 * An earlier addition to "git diff --no-index A B" to limit the
   output with pathspec after the two directories misbehaved when
   these directories were given with a trailing slash, which has been
   corrected.

 * The "--short" option of "git status" that meant output for humans
   and "-z" option to show NUL delimited output format did not mix
   well, and colored some but not all things.  The command has been
   updated to color all elements consistently in such a case.

 * Unicode width table update.

 * Recent OpenSSH creates the Unix domain socket to communicate with
   ssh-agent under $HOME instead of /tmp, which causes our test to
   fail doe to overly long pathname in our test environment, which has
   been worked around by using "ssh-agent -T".

Also contains various documentation updates, code cleanups and minor fixups.

----------------------------------------------------------------

Changes since v2.51.1 are as follows:

Jacob Keller (1):
      diff --no-index: fix logic for paths ending in '/'

Jeff King (2):
      diff: restore redirection to /dev/null for diff_from_contents
      status: make coloring of "-z --short" consistent

Johannes Schindelin (5):
      refs: forbid clang to complain about unreachable code
      build(deps): bump actions/download-artifact from 4 to 5
      build(deps): bump actions/checkout from 4 to 5
      build(deps): bump actions/setup-python from 5 to 6
      build(deps): bump actions/github-script from 7 to 8

Junio C Hamano (2):
      diff: make sure the other caller of diff_flush_patch_quietly() is silent
      Git 2.51.2

Kristoffer Haugsbakk (1):
      doc: fix accidental literal blocks

Patrick Steinhardt (2):
      gitlab-ci: disable realtime monitoring to unbreak Windows jobs
      t7528: work around ETOOMANY in OpenSSH 10.1 and newer

Solly (1):
      t2401: update path checks using test_path helpers

Torsten Bögershausen (1):
      unicode: update the width tables to Unicode 17

[BUGS] Git v2.51.2 on NonStop

[rsbecker]

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).

Many failures in t7900 resulting from the use of test_subcommand ! as seen below. This is run in bash 5.0.18:

+ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
+ 0< run-no-auto.txt
{"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"]}
+ test_subcommand ! git gc --auto --quiet --no-detach --skip-foreground-tasks
+ 0< run-auto.txt
test_subcommand[5]: test: argument expected

Regards,
Randall

Re: [BUGS] Git v2.51.2 on NonStop

[SZEDER Gábor]

On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:
> 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).
> 
> Many failures in t7900 resulting from the use of test_subcommand ! as seen below. This is run in bash 5.0.18:
> 
> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
> + 0< run-no-auto.txt
> {"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"]}
> + test_subcommand ! git gc --auto --quiet --no-detach --skip-foreground-tasks
> + 0< run-auto.txt
> test_subcommand[5]: test: argument expected

This is a strange trace output, as it includes file descriptor
redirections, but lacks the trace of commands executed in
test_subcommands.  This trace doesn't look like it's coming from Bash.

RE: [BUGS] Git v2.51.2 on NonStop

[rsbecker]

On October 29, 2025 6:28 PM, SZEDER Gábor wrote:
>On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:
>> 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).
>>
>> Many failures in t7900 resulting from the use of test_subcommand ! as seen
>below. This is run in bash 5.0.18:
>>
>> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
>> + 0< run-no-auto.txt
>> {"event":"child_start","sid":"20251028T172435.690328Z-H36b1c598-P7b000
>> 02d","thread":"main","time":"2025-10-28T17:24:35.879833Z","file":"/hom
>> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c","line":7
>> 40,"child_id":2,"child_class":"?","use_shell":false,"argv":["git","gc"
>> ,"--quiet","--no-detach","--skip-foreground-tasks"]}
>> + test_subcommand ! git gc --auto --quiet --no-detach
>> + --skip-foreground-tasks 0< run-auto.txt
>> test_subcommand[5]: test: argument expected
>
>This is a strange trace output, as it includes file descriptor redirections, but lacks the
>trace of commands executed in test_subcommands.  This trace doesn't look like it's
>coming from Bash.

The test_subcommand[5]: test: argument expect is coming from bash. I cannot see how
it is coming from anywhere else. The test was run with -x but snipped. Reference to
test_subcommand ! git... fails exactly the same way. Is there something else I can provide?

Re: [BUGS] Git v2.51.2 on NonStop

[SZEDER Gábor]

On Wed, Oct 29, 2025 at 06:41:27PM -0400, rsbecker@nexbridge.com wrote:
> On October 29, 2025 6:28 PM, SZEDER Gábor wrote:
> >On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:
> >> 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).
> >>
> >> Many failures in t7900 resulting from the use of test_subcommand ! as seen
> >below. This is run in bash 5.0.18:
> >>
> >> + test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
> >> + 0< run-no-auto.txt
> >> {"event":"child_start","sid":"20251028T172435.690328Z-H36b1c598-P7b000
> >> 02d","thread":"main","time":"2025-10-28T17:24:35.879833Z","file":"/hom
> >> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c","line":7
> >> 40,"child_id":2,"child_class":"?","use_shell":false,"argv":["git","gc"
> >> ,"--quiet","--no-detach","--skip-foreground-tasks"]}
> >> + test_subcommand ! git gc --auto --quiet --no-detach
> >> + --skip-foreground-tasks 0< run-auto.txt
> >> test_subcommand[5]: test: argument expected
> >
> >This is a strange trace output, as it includes file descriptor redirections, but lacks the
> >trace of commands executed in test_subcommands.  This trace doesn't look like it's
> >coming from Bash.
> 
> The test_subcommand[5]: test: argument expect is coming from bash. I cannot see how
> it is coming from anywhere else. The test was run with -x but snipped. Reference to
> test_subcommand ! git... fails exactly the same way. Is there something else I can provide?

The -x trace from Bash doesn't include file descriptor redirections,
but includes the commands executed in test_subcommand, and the number
of '+' characters at the beginning of each trace line indicates the
number of subshells, so when the test is really run by Bash the trace
from a test_subcommand invocation looks like this:

  ++ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
  ++ local negate=
  ++ test git = '!'
  +++ printf '"%s",' git gc --quiet --no-detach --skip-foreground-tasks
  ++ local 'expr="git","gc","--quiet","--no-detach","--skip-foreground-tasks",'
  ++ expr='"git","gc","--quiet","--no-detach","--skip-foreground-tasks"'
  ++ test -n ''
  ++ grep '\["git","gc","--quiet","--no-detach","--skip-foreground-tasks"\]'
  {"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"]}
  ++ test_subcommand '!' git gc --auto --quiet --no-detach --skip-foreground-tasks
  ++ local negate=

Since the trace you showed doesn't look like this I still doubt that
it came from Bash.

RE: [BUGS] Git v2.51.2 on NonStop

[rsbecker]

On October 29, 2025 7:18 PM, SZEDER Gábor wrote:
>On Wed, Oct 29, 2025 at 06:41:27PM -0400, rsbecker@nexbridge.com wrote:
>> On October 29, 2025 6:28 PM, SZEDER Gábor wrote:
>> >On Tue, Oct 28, 2025 at 01:40:42PM -0400, rsbecker@nexbridge.com wrote:
>> >> 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).
>> >>
>> >> Many failures in t7900 resulting from the use of test_subcommand !
>> >> as seen
>> >below. This is run in bash 5.0.18:
>> >>
>> >> + test_subcommand git gc --quiet --no-detach
>> >> + --skip-foreground-tasks 0< run-no-auto.txt
>> >> {"event":"child_start","sid":"20251028T172435.690328Z-H36b1c598-P7b
>> >> 000
>> >> 02d","thread":"main","time":"2025-10-28T17:24:35.879833Z","file":"/
>> >> hom
>> >> e/jenkinsbuild/.jenkins/workspace/Git_Pipeline/run-command.c","line
>> >> ":7
>> >> 40,"child_id":2,"child_class":"?","use_shell":false,"argv":["git","gc"
>> >> ,"--quiet","--no-detach","--skip-foreground-tasks"]}
>> >> + test_subcommand ! git gc --auto --quiet --no-detach
>> >> + --skip-foreground-tasks 0< run-auto.txt
>> >> test_subcommand[5]: test: argument expected
>> >
>> >This is a strange trace output, as it includes file descriptor
>> >redirections, but lacks the trace of commands executed in
>> >test_subcommands.  This trace doesn't look like it's coming from Bash.
>>
>> The test_subcommand[5]: test: argument expect is coming from bash. I
>> cannot see how it is coming from anywhere else. The test was run with
>> -x but snipped. Reference to test_subcommand ! git... fails exactly the same way.
>Is there something else I can provide?
>
>The -x trace from Bash doesn't include file descriptor redirections, but includes the
>commands executed in test_subcommand, and the number of '+' characters at the
>beginning of each trace line indicates the number of subshells, so when the test is
>really run by Bash the trace from a test_subcommand invocation looks like this:
>
>  ++ test_subcommand git gc --quiet --no-detach --skip-foreground-tasks
>  ++ local negate=
>  ++ test git = '!'
>  +++ printf '"%s",' git gc --quiet --no-detach --skip-foreground-tasks
>  ++ local 'expr="git","gc","--quiet","--no-detach","--skip-foreground-tasks",'
>  ++ expr='"git","gc","--quiet","--no-detach","--skip-foreground-tasks"'
>  ++ test -n ''
>  ++ grep '\["git","gc","--quiet","--no-detach","--skip-foreground-tasks"\]'
>  {"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"]}
>  ++ test_subcommand '!' git gc --auto --quiet --no-detach --skip-foreground-tasks
>  ++ local negate=
>
>Since the trace you showed doesn't look like this I still doubt that it came from Bash.

What appears to be happening is that the Make environment is only using SHELL=/bin/bash
for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh
as specified, which uses ksh, not bash, which is the trace above. When I run the individual
tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,
4.1.2, the SHELL variable is only being replaced for the command processing of each
recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,
and fails out. This means that I have to remember to manually run each test that fails with
bash instead of the default. It is frustrating and now adds hours to my manual evaluation
of the CI/CD results.

The trace above is from sh, not bash because of this.

With Frustration,
Randall

Re: [BUGS] Git v2.51.2 on NonStop

[Jeff King]

On Wed, Oct 29, 2025 at 08:24:52PM -0400, rsbecker@nexbridge.com wrote:

> What appears to be happening is that the Make environment is only using SHELL=/bin/bash
> for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh
> as specified, which uses ksh, not bash, which is the trace above. When I run the individual
> tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,
> 4.1.2, the SHELL variable is only being replaced for the command processing of each
> recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,
> and fails out. This means that I have to remember to manually run each test that fails with
> bash instead of the default. It is frustrating and now adds hours to my manual evaluation
> of the CI/CD results.
> 
> The trace above is from sh, not bash because of this.

Does "make TEST_SHELL_PATH=/bin/bash" work?

The default there is $(SHELL_PATH), which is distinct again from
$(SHELL). The former is a Git-ism for the shell we replace in #! lines
and invoke from within C programs, and the latter is a make-ism for how
to run make recipes. If your /bin/sh isn't fully functional you might
want to be setting SHELL_PATH, too.

-Peff

Re: [BUGS] Git v2.51.2 on NonStop

[D. Ben Knoble]

On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:
>
> What appears to be happening is that the Make environment is only using SHELL=/bin/bash
> for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh
> as specified, which uses ksh, not bash, which is the trace above. When I run the individual
> tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,
> 4.1.2, the SHELL variable is only being replaced for the command processing of each
> recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,
> and fails out. This means that I have to remember to manually run each test that fails with
> bash instead of the default. It is frustrating and now adds hours to my manual evaluation
> of the CI/CD results.
>
> The trace above is from sh, not bash because of this.
>
> With Frustration,
> Randall

Is this the only ksh-induced failure? And if so, what is inducing the
failure—is it something the test library can work around, or is the
system {k,}sh not behaving portably here?

My preference would be towards making your setup "just work" assuming
there's not a clear contradiction of portable standards somewhere.

-- 
D. Ben Knoble

RE: [BUGS] Git v2.51.2 on NonStop

[rsbecker]

On October 30, 2025 9:53 AM, D. Ben Knoble wrote:
>On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:
>>
>> What appears to be happening is that the Make environment is only
>> using SHELL=/bin/bash for the outer processing but not the inner
>> #!/bin/sh of t7900. The system is using /bin/sh as specified, which
>> uses ksh, not bash, which is the trace above. When I run the
>> individual tests with bash, the error reported goes away. The problem
>> is, with my version of Gnu Make, 4.1.2, the SHELL variable is only
>> being replaced for the command processing of each recipe. Once the
>> system loader sees the shebang of #!/bin/sh, /bin/sh is used as
>> requested, and fails out. This means that I have to remember to manually run
>each test that fails with bash instead of the default. It is frustrating and now adds
>hours to my manual evaluation of the CI/CD results.
>>
>> The trace above is from sh, not bash because of this.
>>
>> With Frustration,
>> Randall
>
>Is this the only ksh-induced failure? And if so, what is inducing the failure—is it
>something the test library can work around, or is the system {k,}sh not behaving
>portably here?
>
>My preference would be towards making your setup "just work" assuming there's
>not a clear contradiction of portable standards somewhere.

I think there were other ksh issues, mostly the SHELL= setting in make. I will report
others on a per test case basis when they come. The SHELL_PATH= definitely is
using bash, so that fix suggested by Peff is working out nicely.

Regards,
Randall

Re: [BUGS] Git v2.51.2 on NonStop

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On 2025-10-30 at 13:52:34, D. Ben Knoble wrote:
> On Wed, Oct 29, 2025 at 8:25 PM <rsbecker@nexbridge.com> wrote:
> >
> > What appears to be happening is that the Make environment is only using SHELL=/bin/bash
> > for the outer processing but not the inner #!/bin/sh of t7900. The system is using /bin/sh
> > as specified, which uses ksh, not bash, which is the trace above. When I run the individual
> > tests with bash, the error reported goes away. The problem is, with my version of Gnu Make,
> > 4.1.2, the SHELL variable is only being replaced for the command processing of each
> > recipe. Once the system loader sees the shebang of #!/bin/sh, /bin/sh is used as requested,
> > and fails out. This means that I have to remember to manually run each test that fails with
> > bash instead of the default. It is frustrating and now adds hours to my manual evaluation
> > of the CI/CD results.
> >
> > The trace above is from sh, not bash because of this.
> >
> > With Frustration,
> > Randall
> 
> Is this the only ksh-induced failure? And if so, what is inducing the
> failure—is it something the test library can work around, or is the
> system {k,}sh not behaving portably here?

We know that AT&T ksh (ksh93) doesn't work for Git because we require
`local` and AT&T ksh doesn't offer that.  Other ksh implementations,
such as pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh),
ksh88, and various others, do in fact work just fine because they
support `local`.  The `test_subcommand` function does use `local`,
so that may explain why things aren't working.

ksh (and zsh in zsh mode, but not in sh mode[0]) also run the last command
in a pipeline in the main shell instead of a subshell.  That may also be
a source of incompatibility.

It may also be failing to work for other reasons as well, though.

[0] To be clear, zsh has never successfully run our testsuite in zsh
mode, but it should mostly work in sh mode.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [BUGS] Git v2.51.2 on NonStop

[Kristoffer Haugsbakk]

On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
> 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).
>
> Many failures in t7900 resulting from the use of test_subcommand ! as
> seen below. This is run in bash 5.0.18:
>
>[snip]

Would it make sense for maintenance releases to have a small release
candidate pre-release?  Both of these maintenance releases have had
issues.

RE: [BUGS] Git v2.51.2 on NonStop

[rsbecker]

On October 30, 2025 11:15 AM, Kristoffer Haugsbakk wrote:
>On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>> 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).
>>
>> Many failures in t7900 resulting from the use of test_subcommand ! as
>> seen below. This is run in bash 5.0.18:
>>
>>[snip]
>
>Would it make sense for maintenance releases to have a small release
candidate pre-
>release?  Both of these maintenance releases have had issues.

Interesting question. I would personally prefer that maintenance releases
would be
fixes only, rather than new functionality or introduction of new
dependencies or
constructs that might break the main release. If there is something
significant done,
it should be in a main release, with a release candidate. I think we should
be cutting
down what is in maintenance releases so that release candidates are not
required.

Obviously, if there is a CVE and we need a maintenance release to fix it,
and the CVE
has breaking changes, we have an issue - and if significant enough, then
yes, a
release candidate should be done.

Just my opinion,
Randall

Re: [BUGS] Git v2.51.2 on NonStop

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>> 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).
>>
>> Many failures in t7900 resulting from the use of test_subcommand ! as
>> seen below. This is run in bash 5.0.18:
>>
>>[snip]
>
> Would it make sense for maintenance releases to have a small release
> candidate pre-release?  Both of these maintenance releases have had
> issues.

Well, that is usually called "the tip of 'master'".  Has NonStop
been having issues with the tip of 'master'?  For how long?  Why
haven't we heard about it at all?  After things are merged there
(which requires them to be cooking in 'next'---oh, has NonStop been
having issues with 'next'?  For how long?), only fixes are chosen
and merged to 'maint' to be the next maintenance release.  I doubt
any pre-release on 'maint' has much value in that anybody who are
not testing the tip of 'master' would not be testing it either.

Re: [BUGS] Git v2.51.2 on NonStop

[Kristoffer Haugsbakk]

On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>>>[snip]
>>
>> Would it make sense for maintenance releases to have a small release
>> candidate pre-release?  Both of these maintenance releases have had
>> issues.
>
> Well, that is usually called "the tip of 'master'".  Has NonStop
> been having issues with the tip of 'master'?  For how long?  Why
> haven't we heard about it at all?  After things are merged there
> (which requires them to be cooking in 'next'---oh, has NonStop been
> having issues with 'next'?  For how long?), only fixes are chosen
> and merged to 'maint' to be the next maintenance release.
> ...
> I doubt any pre-release on 'maint' has much value in that anybody who
> are not testing the tip of 'master' would not be testing it either.

You are probably 99.9% likely to be correct.

RE: [BUGS] Git v2.51.2 on NonStop5

[rsbecker]

On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:
>On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:
>> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>
>>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>>>>[snip]
>>>
>>> Would it make sense for maintenance releases to have a small release
>>> candidate pre-release?  Both of these maintenance releases have had
>>> issues.
>>
>> Well, that is usually called "the tip of 'master'".  Has NonStop been
>> having issues with the tip of 'master'?  For how long?  Why haven't we
>> heard about it at all?  After things are merged there (which requires
>> them to be cooking in 'next'---oh, has NonStop been having issues with
>> 'next'?  For how long?), only fixes are chosen and merged to 'maint'
>> to be the next maintenance release.
>> ...
>> I doubt any pre-release on 'maint' has much value in that anybody who
>> are not testing the tip of 'master' would not be testing it either.
>
>You are probably 99.9% likely to be correct.

We tried setting up a CI/CD process for git on NonStop. The problem is that
we use Jenkins, which gets triggered each time a change is made on a branch.
The actual difficulty is that a single run takes more than a day. Once the
committer adds each commit to a branch, we end up with a queue that is
2-3 weeks long, so end up not running a continuous process. Instead, we
run about 1 a week, which should catch things. The difficulty is with the
latest release is that 2.25.2 came out before our cycle and the breaks were
in there because of changes to one test that just did not end up dequeuing
in time. NonStop is building and testing fine now after Peff's suggestion on
SHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this
issue with our inadvertent use of ksh to run each test script.

Re: [BUGS] Git v2.51.2 on NonStop5

[SZEDER Gábor]

On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote:
> On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:
> >On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:
> >> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
> >>
> >>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
> >>>>[snip]
> >>>
> >>> Would it make sense for maintenance releases to have a small release
> >>> candidate pre-release?  Both of these maintenance releases have had
> >>> issues.
> >>
> >> Well, that is usually called "the tip of 'master'".  Has NonStop been
> >> having issues with the tip of 'master'?  For how long?  Why haven't we
> >> heard about it at all?  After things are merged there (which requires
> >> them to be cooking in 'next'---oh, has NonStop been having issues with
> >> 'next'?  For how long?), only fixes are chosen and merged to 'maint'
> >> to be the next maintenance release.
> >> ...
> >> I doubt any pre-release on 'maint' has much value in that anybody who
> >> are not testing the tip of 'master' would not be testing it either.
> >
> >You are probably 99.9% likely to be correct.
> 
> We tried setting up a CI/CD process for git on NonStop. The problem is that
> we use Jenkins, which gets triggered each time a change is made on a branch.
> The actual difficulty is that a single run takes more than a day. Once the
> committer adds each commit to a branch, we end up with a queue that is
> 2-3 weeks long, so end up not running a continuous process. Instead, we
> run about 1 a week, which should catch things. The difficulty is with the
> latest release is that 2.25.2 came out before our cycle and the breaks were
> in there because of changes to one test that just did not end up dequeuing
> in time. NonStop is building and testing fine now after Peff's suggestion on
> SHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this
> issue with our inadvertent use of ksh to run each test script.

Neither the test library nor t7900 changed in the last two maintenance
releases:

  $ git rev-list --count v2.51.0..v2.51.2 -- t/test-lib.sh t/test-lib-functions.sh t/t7900-maintenance.sh
  0

RE: [BUGS] Git v2.51.2 on NonStop5

[rsbecker]

On October 30, 2025 6:31 PM, SZEDER Gábor wrote:
>On Thu, Oct 30, 2025 at 05:46:01PM -0400, rsbecker@nexbridge.com wrote:
>> On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:
>> >On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:
>> >> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>> >>
>> >>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>> >>>>[snip]
>> >>>
>> >>> Would it make sense for maintenance releases to have a small
>> >>> release candidate pre-release?  Both of these maintenance releases
>> >>> have had issues.
>> >>
>> >> Well, that is usually called "the tip of 'master'".  Has NonStop
>> >> been having issues with the tip of 'master'?  For how long?  Why
>> >> haven't we heard about it at all?  After things are merged there
>> >> (which requires them to be cooking in 'next'---oh, has NonStop been
>> >> having issues with 'next'?  For how long?), only fixes are chosen and merged to
>'maint'
>> >> to be the next maintenance release.
>> >> ...
>> >> I doubt any pre-release on 'maint' has much value in that anybody
>> >> who are not testing the tip of 'master' would not be testing it either.
>> >
>> >You are probably 99.9% likely to be correct.
>>
>> We tried setting up a CI/CD process for git on NonStop. The problem is
>> that we use Jenkins, which gets triggered each time a change is made on a branch.
>> The actual difficulty is that a single run takes more than a day. Once
>> the committer adds each commit to a branch, we end up with a queue
>> that is
>> 2-3 weeks long, so end up not running a continuous process. Instead,
>> we run about 1 a week, which should catch things. The difficulty is
>> with the latest release is that 2.25.2 came out before our cycle and
>> the breaks were in there because of changes to one test that just did
>> not end up dequeuing in time. NonStop is building and testing fine now
>> after Peff's suggestion on SHELL_PATH, but that was only apparent at
>> 2.52.2. 2.51.1 did not have this issue with our inadvertent use of ksh to run each
>test script.
>
>Neither the test library nor t7900 changed in the last two maintenance
>releases:
>
>  $ git rev-list --count v2.51.0..v2.51.2 -- t/test-lib.sh t/test-lib-functions.sh
>t/t7900-maintenance.sh
>  0

Honestly, I do not know. I am just reporting my experience from my own
CI/CD system. All builds are from scratch. Given that I am now using bash,
the situation is resolved as far as I am concerned. If the team wants me to
try to do a bisect, I can, but it will take weeks to do this based on how long
the compile/test cycles are.

RE: [BUGS] Git v2.51.2 on NonStop5

[rsbecker]

On October 30, 2025 5:46 PM, I wrote:
>To: 'Kristoffer Haugsbakk' <kristofferhaugsbakk@fastmail.com>; 'Junio C
Hamano'
><gitster@pobox.com>
>Cc: git@vger.kernel.org
>Subject: RE: [BUGS] Git v2.51.2 on NonStop5
>
>On October 30, 2025 4:26 PM, Kristoffer Haugsbakk wrote:
>>On Thu, Oct 30, 2025, at 20:42, Junio C Hamano wrote:
>>> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>>
>>>> On Tue, Oct 28, 2025, at 18:40, rsbecker@nexbridge.com wrote:
>>>>>[snip]
>>>>
>>>> Would it make sense for maintenance releases to have a small release
>>>> candidate pre-release?  Both of these maintenance releases have had
>>>> issues.
>>>
>>> Well, that is usually called "the tip of 'master'".  Has NonStop been
>>> having issues with the tip of 'master'?  For how long?  Why haven't we
>>> heard about it at all?  After things are merged there (which requires
>>> them to be cooking in 'next'---oh, has NonStop been having issues with
>>> 'next'?  For how long?), only fixes are chosen and merged to 'maint'
>>> to be the next maintenance release.
>>> ...
>>> I doubt any pre-release on 'maint' has much value in that anybody who
>>> are not testing the tip of 'master' would not be testing it either.
>>
>>You are probably 99.9% likely to be correct.
>
>We tried setting up a CI/CD process for git on NonStop. The problem is that
>we use Jenkins, which gets triggered each time a change is made on a
branch.
>The actual difficulty is that a single run takes more than a day. Once the
>committer adds each commit to a branch, we end up with a queue that is
>2-3 weeks long, so end up not running a continuous process. Instead, we
>run about 1 a week, which should catch things. The difficulty is with the
>latest release is that 2.25.2 came out before our cycle and the breaks were
>in there because of changes to one test that just did not end up dequeuing
>in time. NonStop is building and testing fine now after Peff's suggestion
on
>SHELL_PATH, but that was only apparent at 2.52.2. 2.51.1 did not have this
>issue with our inadvertent use of ksh to run each test script.

The current CI/CD run passed with only t9001 failing as expected. I am
wondering whether we could add a switch like SENDMAIL=NoThanks. There
is an object called sendmail on the box I am on, but it is not a compliant
port - someone tried this decades ago.