Twice have git (2.8.3) stopped working for me on Cygwin. Last time I fixed it with a reinstall of the complete Cygwin (x86_64 on Windows 10), but since this now happened again (possibly after an update of Cygwin (2.5.2) and Windows) I'd like some help to dig deeper.
There are a lot of questions on StackOverflow and elsewhere around the failing unpack-objects and index-pack but most seem to be related to large repos, low disk, memory or flaky networks. Neither apply here I think (1.2TB disk free, 8GB memory, successful git operations with native git on same machine...)
Short story:
In a local repo I can do git status which indicates no problems, and that I'm ahead and should push. git push says "fetch first" and git fetch says
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 37 (delta 16), reused 0 (delta 0), pack-reused 0
fatal: unpack-objects failed
There is no problem with disk space or memory, or with file protections (AFAICS). The remote is on github and I can successfully do ssh -vT so no problem with ssh either.
$ git gc
error: failed to run pack-refs
Indicates that it might be a corrupted repo:
$ git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (6051/6051), done.
dangling blob 42.....
So no problem there, so I try to clone a fresh copy and get
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 37 (delta 16), reused 0 (delta 0), pack-reused 0
fatal: unpack-objects failed
Everything else that I've tried in Cygwin (like compilation, running most usual commands, cd etc. etc.) works as it should. So any ideas what to try next?
Long story (with more details and logs): I can supply complete logs (as indicated by a comment to this question) with
GIT_TRACE=2
GIT_CURL_VERBOSE=2
GIT_TRACE_PERFORMANCE=2
GIT_TRACE_PACK_ACCESS=2
GIT_TRACE_PACKET=2
GIT_TRACE_PACKFILE=2
GIT_TRACE_SETUP=2
GIT_TRACE_SHALLOW=2
-v -v
from all the above commands. Most of them end like this (git clone)
10:39:13.934233 run-command.c:336 trace: run_command: 'fetch' '--update-head-ok' '-v' '-v'
10:39:13.938071 exec_cmd.c:120 trace: exec: 'git' 'fetch' '--update-head-ok' '-v' '-v'
10:39:13.951802 trace.c:420 performance: 0.058074148 s: git command: 'git' 'pull' '-v' '-v'
indicating that it tries to run the fetch but then just exits ("performance:" is the last trace message in all cases, since we have GIT_TRACE_PERFORMANCE).
Most surprising possibly is the trace from git fetch --update-head-ok (which is what git tries to do in many cases. That trace continues on for a while with syncing hashs, but then
09:14:48.260420 pkt-line.c:80 packet: sideband< \2Compressing objects: 100% (37/37) \15
09:14:48.260449 pkt-line.c:80 packet: sideband< \2Compressing objects: 100% (37/37), done.
remote: Compressing objects: 100% (37/37), done.
PACK%▒x▒▒▒An▒ ▒~▒=▒d3▒1C▒▒▒
The last line is the start of some thing that looks like the dump of a binary file, which then terminates with
09:14:48.379400 pkt-line.c:80 37 (delta 16), reused 0 (delta 0), pack-reused 0
remote: Total 37 (delta 16), reused 0 (delta 0), pack-reused 0
09:14:48.387949 pkt-line.c:80 packet: sideband< 0000
09:14:48.387950 exec_cmd.c:120 trace: exec: 'git' 'unpack-objects' '--pack_header=2,37'
fatal: unpack-objects failed
09:14:48.406747 trace.c:420 performance: 2.140411798 s: git command: 'git' 'fetch' '--update-head-ok' '-v'
What should be my next move? (yes, I've asked on the cygwin mailing list too.)
This is mostly documentation for posterity ;-)
This was a User error, of course.
I had decided to install 32-bit Cygwin in parallel to my 64-bit. So I installed a fresh 64 under /cygwin64 and a 32-bit under /cygwin32. That left me with three "cygwins" on my C: drive, /cygwin64, /cygwin32 and the original /cygwin. I don't know why but
/cygwin got brokenSo, whenever I used that shortcut it looked like Git was broken. I have no clue as to why Git could not give anything more useful as output when it died, though... Or why it did...
But running consistent version makes everything work as expected ,-)