问题
I am facing a problem with a Git repository stored on GitLab. It seems to be a repository issue only affecting this specific repository, as all other projects hosted on GitLab are working fine.
It seems I can personally push, pull, and checkout branches using GitKraken, but when I try to pull from Git Bash I get the following:
$ git pull
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: Could not read bb5a805503a3da247038200df7002f452a8781e9
fatal: bad tree object bb5a805503a3da247038200df7002f452a8781e9
error: failed to run repack
All people cooperating with me on this same project have similar issues when attempting to pull:
$ git pull
remote: Enumerating objects: 112, done.
remote: Counting objects: 100% (112/112), done.
remote: Compressing objects: 100% (102/102), done.
fatal: pack has bad object at offset 8105548: inflate returned -5
fatal: index-pack failed
And this is what we all get when trying to clone the repository on a new location:
remote: Enumerating objects: 4364, done.
remote: Counting objects: 100% (4364/4364), done.
remote: Compressing objects: 100% (1622/1622), done.
fatal: pack has bad object at offset 56589977: inflate returned -5
fatal: index-pack failed
These are the things we tried:
- Tested multiple computers
- Tested multiple users
I suspect, reading similar questions such as this one, that our repository is broken. However, I don't understand why I seem to be able to work with it via GitKraken. With its GUI, I successfully merged two branches and pushed the latest commits to the server.
Does anybody have an explanation of what could be the problem?
Edit: attempt of fixing the repository
Following these instructions contained in the link I posted, and also suggested by an answer below, I ran the command git fsck --full to examine the state of the repository links. What I found is not reassuring, as it seems many links are broken.
Checking object directories: 100% (256/256), done.
Checking objects: 100% (3769/3769), done.
broken link from commit f42ccacb8101ef49493aca18089378697490bb66
to tree e461e3cbe3221cd5ba7035222aa716dcabb63713
broken link from commit 2fe8ac2b06d8e8f37b354c395f60a77f0ab1f9a9
to tree 93b9618cc159c1b18aba319e8f7e3e5e8f7b57df
broken link from commit 16d23305969b3a40316618b952b2e5ff1ffedbf6
to tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
broken link from tree 867941d734b41a5ce800dff6ea7dbfca30787e15
to tree bb5a805503a3da247038200df7002f452a8781e9
broken link from tree e16211709ea4ce02a89bbe87d30a410dac65e372
to blob b6eb83a9e4f16fe49a0eb9bfea0bf6dfce9adcbc
broken link from tree e16211709ea4ce02a89bbe87d30a410dac65e372
to blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
broken link from tree e16211709ea4ce02a89bbe87d30a410dac65e372
to blob 652245900beb49246e58f5c216dbcf161f727e2d
broken link from tree e16211709ea4ce02a89bbe87d30a410dac65e372
to blob a7998441f7435126feb6b35e9b4b575bd193d6d2
followed by a long list of dangling commit and dangling blob lines with 8 instances of missing ones:
[...]
missing tree 80c4012d9f3b3f51f17932dec80e740bc4e5a1d6
[...]
missing blob a593c8f43faacf41bc93c98dbb347e673cd47f3f
[...]
[6 more]
It seems like a manual recovery of the broken files would take quite some time.
Edit #2: fixed repository locally
I installed and ran git-repair in my local copy of the repository, and actually got it fixed. If I now run git fsck --full I only see "healthy" messages in response. No more broken links.
However, no matter if I git push --force to origin, it seems origin remains broken. One weird update is that now I can use git clone successfully, while all my co-workers still cannot. How can it be?
And most importantly, is there a way I can actually run git-repair on origin?
Edit #3: Made new origin
After fixing my repository locally (and checked that git fsck gives no missing links) I pushed all relevant branches to a fresh origin on GitLab. I thought that was going to be it, but unfortunately the problem persists.
A pattern I start to notice is that we seem to all be able to clone from Ubuntu (either using Git Bash or GitKraken) but not on Windows 10 (neither using Git Bash nor GitKraken).
Reading around the website I found a question about how could it be possible that Git worked on Linux but not on Windows. There they explained it was a Git-related issue (but it was more than 1 year ago). Would it make sense something similar has happened? I have to say I'm skeptical about it, because other repositories we tested with work fine on Windows.
Edit #4: tested with older versions of Git for Windows
Current version is 2.19. I tried it on 2.18 and 2.9 (the latter dating 2016) but I get the same error.
Edit #5: tried cloning locally successfully
After a suggestion on a GitHub issue I wrote on git-for-windows, I tried to use git clone from a copy of the repository on a USB stick. It worked. The problem seems to be confined to either Git+Windows+GitLab or Git+Windows+SSH.
回答1:
As the linked answer points out, most of the objects in the tree are diffed and compressed to save bandwidth and disk, creating the mentioned .pack files.
During the pull process, the git client exchanges with the remote a list of refs and heads, so the remote can walk them and compute what objects need to be sent based on what the client already has. It then creates the packs And sends them to the client. This means that a pack sent to a client could be different from another for the same object.
As for why, I couldn't tell, but it's plausible that your repo is skipping the conflicting object, although since different clients throw this error in the same working copy this seems unlikely and looks like it might be just a software issue, maybe differences in the zlib used by each client.
You could try to force-push your repo (not recommended) or pushing to other remote as a last resort.
Also, from the answer you link, there's a procedure to try and fix broken repositories.
UPDATE: As a followup, -5 is Z_BUF_ERROR on zlib and according to the documentation:
inflate() returns Z_OK if some progress has been made [...] Z_BUF_ERROR if no progress was possible or if there was not enough room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR is not fatal, and inflate() can be called again with more input and more output space to continue decompressing. If Z_DATA_ERROR is returned[...]
I personally think the bug is in the software, rather than in GitLab, but that's speculation on my part.
And a suggestion: If it's not possible to move all devs to Linux... What about the Linux subsystem for W10 ?
来源：https://stackoverflow.com/questions/52428788/git-returns-failed-to-run-repack-and-inflate-returned-errors