From: Patrick Steinhardt <ps@pks.im>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2026, #06)
Date: Thu, 22 Oct 2026 08:36:49 +0200 [thread overview]
Message-ID: <atmvASAoaCIpc_ca@pks.im> (raw)
In-Reply-To: <20261022043758.GA31562@tb-raspi4>
On Thu, Oct 22, 2026 at 06:37:58AM +0200, Torsten Bögershausen wrote:
> 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
prev parent reply other threads:[~2026-10-22 6:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 23:02 What's cooking in git.git (Oct 2026, #06) Junio C Hamano
2026-10-20 18:51 ` Torsten Bögershausen
2026-10-21 5:45 ` Patrick Steinhardt
2026-10-21 17:46 ` Junio C Hamano
2026-10-22 4:37 ` Torsten Bögershausen
2026-10-22 6:36 ` Patrick Steinhardt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atmvASAoaCIpc_ca@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox