RE: [ANNOUNCE] Git v2.35.0-rc1

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Jan 17, 2022, 18:52 UTC
Message-ID: <027301d80bd3$5c5b6c50$151244f0$@nexbridge.com>
In-Reply-To: <xmqqy23eurut.fsf@gitster.g>

On January 17, 2022 1:42 PM, Junio C Hamano wrote:

> <rsbecker@nexbridge.com> writes:
> 
> > On January 14, 2022 9:19 PM, Junio wrote:
> >> A release candidate Git v2.35.0-rc1 is now available for testing at the

usual

Show 5 quoted lines

> places.
> >> It is comprised of 467 non-merge commits since v2.34.0, contributed
> >> by 80 people, 32 of which are new faces [*].
> >
> > FYI: rc1 built/test (mostly) passes on both NonStop x86 and ia64

platforms.

Show 18 quoted lines

> >
> > We seem to have a recurrence of a transient failure in t5562 from a few
> releases ago. Retesting makes the problem disappear.
> >
> > Subtest 8
> > #
> > #		test_env HTTP_CONTENT_ENCODING="gzip" test_http_env upload
> empty_body &&
> > #		! verify_http_result "200 OK"
> > #
> > Subtest 14
> > #
> > #		test_env HTTP_CONTENT_ENCODING="gzip" test_http_env
> receive empty_body &&
> > #		! verify_http_result "200 OK"
> > #
> >
> > Am I mistaken that using the ! verify_http_result construct is not

recommended

Show 8 quoted lines

> or am I misremembering the discussion?
> >
> > Regards,
> > --Randall
> 
> I do not recall anything about that shell function.
> 
> I found a half-thread with similar-looking report on an obscure system,

since the

> 2.25 era:
> 
>

https://lore.kernel.org/git/nycvar.QRO.7.76.6.2003252000200.46@tvgsbejvaqbjf .

Show 8 quoted lines

> bet/
> 
> And then from you that is even older, in the 2.21 era:
> 
> https://lore.kernel.org/git/002201d4c560$5a319c40$0e94d4c0$@nexbridge.co
> m/
> 
> But neither seems to lead to a discussion on the use of verify_http_result

helper.

We transitioned from the platform default ksh to bash for build/test of git right after that point that cleared the issue. It looks like there could be a regression in bash introduced on the platform very recently (June 2021) that may be responsible unless /bin/sh is referenced directly in the scripts. I will check. --Randall