From: rsbecker@nexbridge.com
Date: Wed, 08 Apr 2026 14:54:00 GMT
Subject: RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327
Message-ID: <011701dcc767$8c2ab400$a4801c00$@nexbridge.com>
In-Reply-To: <20260408041716.GA1324339@coredump.intra.peff.net>

On April 8, 2026 12:17 AM, Jeff King wrote:
>On Tue, Apr 07, 2026 at 07:29:50PM -0400, rsbecker@nexbridge.com wrote:
>
>> I can getting numerous issues in t5310, t5326, t2527 relating to the
>> following use of --git-dir:
>>
>> In t5310:
>> fatal: not a git repository: 'clone.git'
>> not ok 55 - fetch (full bitmap)
>> #
>> #                       git --git-dir=clone.git fetch origin second:second
>> &&
>> #                       git rev-parse HEAD >expect &&
>> #                       git --git-dir=clone.git rev-parse HEAD >actual &&
>> #                       test_cmp expect actual
>> #
>
>This test hasn't changed recently. The clone.git directory should have been created
>by an earlier test. Can you try running with "-i" and make sure that this is the first
>failing test, and we didn't fail earlier?
>
>Especially because...
>
>> In t5326 and t5327:
>> fatal: writev error: Invalid function argument
>> fetch-pack: unexpected disconnect while reading sideband packet
>> fatal: early EOF
>> fatal: fetch-pack: invalid index-pack output not ok 24 - clone from
>> bitmapped repository #
>> #                       rm -fr clone.git &&
>> #                       git clone --no-local --bare . clone.git &&
>> #                       git rev-parse HEAD >expect &&
>> #                       git --git-dir=clone.git rev-parse HEAD >actual &&
>> #                       test_cmp expect actual
>> #
>
>...it looks less like --git-dir is a problem here, and more like the introduction of
>writev() is. It is now used in sideband_send(), so it seems plausible that a similar
>failure might have broken the git-clone operation that the other test was using to
>create clone.git.
>
>As for why writev() is failing, I don't know. If it were totally broken on your system
>I'd expect almost everything to be failing. But maybe try building with "make
>NO_WRITEV=Nope" and see if that makes the problems go away? The compat
>implementation just does a series of write() calls, which is what send_sideband()
>was doing before.

First fail is as follows in subtest 25:

expecting success of 5310.25 'clone from bitmapped repository':
                rm -fr clone.git &&
                git clone --no-local --bare . clone.git &&
                git rev-parse HEAD >expect &&
                git --git-dir=clone.git rev-parse HEAD >actual &&
                test_cmp expect actual

Cloning into bare repository 'clone.git'...
remote: Enumerating objects: 629, done.
fatal: writev error: Invalid function argument
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
not ok 25 - clone from bitmapped repository

I think the invalid function argument maybe an ioctl or socketioctl not supported for the file type.