Re: What's cooking in git.git (Oct 2026, #06)

From: Patrick Steinhardt <ps@pks.im>
Date: Oct 22, 2026, 06:36 UTC
Message-ID: <atmvASAoaCIpc_ca@pks.im>
In-Reply-To: <20261022043758.GA31562@tb-raspi4>

On Thu, Oct 22, 2026 at 06:37:58AM +0200, Torsten Bögershausen wrote:

Show 31 quoted lines

> On Wed, Oct 21, 2026 at 10:46:53AM -0700, Junio C Hamano wrote:
> > Patrick Steinhardt <ps@pks.im> writes:
> > 
> > > diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
> > > index 16cc5d5dcb..a19bb27db7 100755
> > > --- a/t/t1450-fsck.sh
> > > +++ b/t/t1450-fsck.sh
> > > @@ -544,6 +544,7 @@ test_expect_success 'rev-list --verify-objects with truncated loose blob' ' 
> > >  		cd truncated-blob &&
> > >  		blob=$(test-tool genrandom one 5k | git hash-object -t blob -w --stdin) &&
> > >  		obj=.git/objects/$(test_oid_to_path $blob) &&
> > > +		chmod +w $obj &&
> > >  		# Truncate the loose blob such that its header can still be
> > >  		# parsed, but reading the object data fails mid-stream.
> > >
> > > Ah, right, that makes sense. Makes me wonder why none of our tests in CI
> > > hit this error. Weird.
> > 
> > Not just CI.  I haven't seen this fail locally, either.  Is the
> > breakage Torsten reports that the later step
> > 
> > 	mv obj.tmp "$obj"
> > 
> > fail when $obj" is not writable?  That does not make sense to me.
> > 
> > > Junio, as this patch series is already in "next", do you want me to send
> > > a patch on top to fix it or shall I send a new version?
> 
> After a (very short) digging:
> It is an old version of bash that was shipped with MacOs:
>  GNU bash, version 5.3.15(1)-release (x86_64-apple-darwin20.6.0)

This release isn't old at all, it's from this year.

> My explanation is that this shell tries to be nice to the user:
> A read-only file sould not be "moved over" by a different file.
> I can probably creata a proper patch the next days - or review
> a patch from someone - whatever is faster.

But does that explanation make sense? If it's mv(1) that fails then Bash is not involved in that decision at all, as mv(1) is part of the BSD utilities.

Could you maybe provide the trace to see what exactly is failing? That might enlighten us.

Thanks!

Patrick