git/list[1] front-page[2] threads[3] people[4] search[5] about
 

RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date
Apr 8, 2026, 16:25 UTC
Message-ID
<013301dcc774$5e9fffb0$1bdfff10$@nexbridge.com>
In-Reply-To
<011701dcc767$8c2ab400$a4801c00$@nexbridge.com>
On April 8, 2026 10:54 AM, I wrote:
Show 70 quoted lines
>To: 'Jeff King' <peff@peff.net>
>Cc: git@vger.kernel.org
>Subject: RE: Git 2.54.0-rc1, subtests of t5310, t5326, t5327
>
>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.

This is also impacting t5608 and t7700. Anywhere where writev() is used, seemingly. We went through MAX_IO_SIZE issues years ago, instead of using ssize_t as a basis of how big communication is. I think writev() is not valid. It worked on Lunix, but had issues elsewhere. This broke the compat layer.

Previous: rsbecker@nexbridge.comNext: Jeff King
Message 4 of 29 in “Git 2.54.0-rc1, subtests of t5310, t5326, t5327”
  1. rsbecker@nexbridge.comApr 7, 2026
  2. Jeff KingApr 8, 2026
  3. rsbecker@nexbridge.comApr 8, 2026
  4. rsbecker@nexbridge.comApr 8, 2026
  5. Jeff KingApr 8, 2026
  6. Junio C HamanoApr 8, 2026
  7. rsbecker@nexbridge.comApr 8, 2026
  8. Junio C HamanoApr 8, 2026
  9. rsbecker@nexbridge.comApr 8, 2026
  10. Junio C HamanoApr 8, 2026
  11. rsbecker@nexbridge.comApr 8, 2026
  12. Junio C HamanoApr 8, 2026
  13. Junio C HamanoApr 8, 2026
  14. rsbecker@nexbridge.comApr 8, 2026
  15. Jeff KingApr 8, 2026
  16. brian m. carlsonApr 9, 2026
  17. Patrick SteinhardtApr 9, 2026
  18. Phillip WoodApr 9, 2026
  19. Patrick SteinhardtApr 9, 2026
  20. rsbecker@nexbridge.comApr 9, 2026
  21. Jeff KingApr 9, 2026
  22. rsbecker@nexbridge.comApr 9, 2026
  23. Jeff KingApr 9, 2026
  24. Patrick SteinhardtApr 10, 2026
  25. Jeff KingApr 9, 2026
  26. Johannes SixtApr 10, 2026
  27. rsbecker@nexbridge.comApr 8, 2026
  28. Jeff KingApr 8, 2026
  29. Jeff KingApr 8, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.