RE: git ftbfs on s390x (test failures)

Hi,

I had written to the community.
Seems like they already have a more versatile fix.
The fix has already been merged to `next`.
I am providing the reply I received.

https://lore.kernel.org/git/[email protected]/

Thanks,
Pranav

________________________________________
From: Pranav P <[email protected]>
Sent: Tuesday, April 22, 2025 4:30 PM
To: Bastian Blank; debian-s390; [email protected]; elbrus; elbrus
Subject: Re: [EXTERNAL] Re: git ftbfs on s390x (test failures)

Hi,

I was able to narrow down the problem and I do have an idea for a fix.

diff --git a/builtin/backfill.c b/builtin/backfill.c
index 33e1ea2f84..18f9701487 100644
--- a/builtin/backfill.c
+++ b/builtin/backfill.c
@@ -123,7 +123,7 @@ int cmd_backfill(int argc, const char **argv, const char *prefix, struct reposit
                .sparse = 0,
        };
        struct option options[] = {
-               OPT_INTEGER(0, "min-batch-size", &ctx.min_batch_size,
+               OPT_MAGNITUDE(0, "min-batch-size", &ctx.min_batch_size,
                            N_("Minimum number of objects to request at a time")),
                OPT_BOOL(0, "sparse", &ctx.sparse,
                         N_("Restrict the missing objects to the current sparse-checkout")),


This is passing all of the test cases. But with this change a size_t pointer is being cast to an unsigned long pointer.
This could potentially lead to some issue in some architecture.
If I can verify that the min_batch_size variable (which is a size_t var) is not taking a value larger than an int could store, then we can change its data type from size_t to int. So, I was checking if there is any evidence that indicates a potential range for min_batch_size.
I was also planning to ping with the upstream community for clarification.

Thanks,
Pranav