From: Todd Zullinger <tmz@pobox.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [ANNOUNCE] Git v2.49.0-rc1
Date: Tue, 4 Mar 2025 13:37:26 -0500 [thread overview]
Message-ID: <Z8dIZmscTdi8dZAY@teonanacatl.net> (raw)
In-Reply-To: <xmqqjz94r8p0.fsf@gitster.g>
Junio C Hamano wrote:
> A release candidate Git v2.49.0-rc1 is now available for testing at
> the usual places. It is comprised of 367 non-merge commits since
> v2.48.0, contributed by 68 people, 17 of which are new faces [*].
[...]
> * Lazy-loading missing files in a blobless clone on demand is costly
> as it tends to be one-blob-at-a-time. "git backfill" is introduced
> to help bulk-download necessary files beforehand.
In <Z8HW6petWuMRWSXf@teonanacatl.net>, I noted that one of the git
backfill command's test fails on s390x:
expecting success of 5620.4 'do partial clone 2, backfill min batch size':
git clone --no-checkout --filter=blob:none \
--single-branch --branch=main \
"file://$(pwd)/srv.bare" backfill2 &&
GIT_TRACE2_EVENT="$(pwd)/batch-trace" git \
-C backfill2 backfill --min-batch-size=20 &&
# Batches were used
test_trace2_data promisor fetch_count 20 <batch-trace >matches &&
test_line_count = 2 matches &&
test_trace2_data promisor fetch_count 8 <batch-trace &&
# No more missing objects!
git -C backfill2 rev-list --quiet --objects --missing=print HEAD >revs2 &&
test_line_count = 0 revs2
+++ pwd
++ git clone --no-checkout --filter=blob:none --single-branch --branch=main 'file:///tmp/git-t.6AFX/trash directory.t5620-backfill/srv.bare' backfill2
ok 3 - do partial clone 1, backfill gets all objects
Cloning into 'backfill2'...
+++ pwd
++ GIT_TRACE2_EVENT='/tmp/git-t.6AFX/trash directory.t5620-backfill/batch-trace'
++ git -C backfill2 backfill --min-batch-size=20
++ test_trace2_data promisor fetch_count 20
++ grep -e '"category":"promisor","key":"fetch_count","value":"20"'
error: last command exited with $?=1
not ok 4 - do partial clone 2, backfill min batch size
Being a new command, perhaps it's not terrible if it doesn't
work on a less popular architecture, but I don't want to let
it slip past without anyone noticing.
As I mentioned the other day, I don't have shell access to
the s390x host, but can run the test suite with additional
debugging if needed. I have the test-results directory from
the build as well.
If anyone wants to poke at it, the full build log (which
contains the test-results directory as a base64-encoded,
zst-compressed tar archive) can be found here for a few
weeks:
https://kojipkgs.fedoraproject.org//work/tasks/7999/129807999/build.log
--
Todd
next prev parent reply other threads:[~2025-03-04 18:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 17:45 [ANNOUNCE] Git v2.49.0-rc1 Junio C Hamano
2025-03-04 18:37 ` Todd Zullinger [this message]
2025-03-04 19:42 ` Junio C Hamano
2025-03-05 1:05 ` rsbecker
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=Z8dIZmscTdi8dZAY@teonanacatl.net \
--to=tmz@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=stolee@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.