new git update fails with fatal: fetch-pack: invalid index-pack output

Mon May 27 20:30:54 GMT 2024

On 2024年5月26日 at 23:45, David Dyck via Cygwin <cygwin@cygwin.com> wrote:
>> After updating I still get the same error.
>> $ git clone -v https://github.com/lxml/lxml.git
> Cloning into 'lxml'...
> POST git-upload-pack (175 bytes)
> POST git-upload-pack (gzip 8652 to 4282 bytes)
> remote: Enumerating objects: 33941, done.
> remote: Counting objects: 100% (3786/3786), done.
> remote: Compressing objects: 100% (1328/1328), done.
> remote: Total 33941 (delta 2360), reused 3474 (delta 2243), pack-reused
> 30155
> Receiving objects: 100% (33941/33941), 20.20 MiB | 17.42 MiB/s, done.
> fatal: fetch-pack: invalid index-pack output
>>> $ cygcheck -srv >cygcheck.out
> cygcheck: dump_sysinfo: GetVolumeInformation() for drive S: failed: 53
>> $ git --version
> git version 2.45.1
>> $ cygcheck -c git
> Cygwin Package Information
> Package Version Status
> git 2.45.1-1 OK
>> $ type git
> git is hashed (/usr/bin/git)
>> attached cygcheck.out

I've just set up a test sandbox with the same set of Cygwin
applications installed, and I'm still not able to replicate this
failure, which is going to make it difficult to work out what's going
wrong for you!
I note your Cygwin PATH has several entries before /bin, including a
~/bin that apparently contains a perl executable; can you see if you
can reproduce the problem with a clean PATH?
In any case, I'm having to conclude the issue is something odd about
your environment that doesn't seem to be affecting most people.
Working out what's going wrong will probably require isolating what
difference is relevant here. I think there's two obvious routes to
doing that: you can work out what's odd about your environment (maybe
use Windows Sandbox, given you're running Windows Enterprise? I've
attached a .wsb file that should give you a starting point for setting
up test environments, based on your cygcheck.out), or you can work out
what's changed in Git between 2.42.0 and 2.45.1, which will probably
mean building and bisecting Git yourself; once we know what change is
the culprit, that'll make it much easier to work out what's going
wrong.
If it'd be useful, I can provide some test builds of Git to help
narrow down where the problem is, but if you can do the builds
yourself, that'll be a lot quicker than trying to do a binary chop by
email…
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygwintest.wsb
Type: application/octet-stream
Size: 9970 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20240527/b05521cf/attachment.obj>