[tom1@achse /data/tomsData/github]$ git clone https://github.com/github/hub.git
Klone nach 'hub' ...
remote: Counting objects: 13716, done.
remote: Compressing objects: 100% (53/53), done.
error: object 9ef2af57366f63deb751b92a8ca630fe598b10f0: zeroPaddedFilemode: contains zero-padded file modes
fatal: Fehler in Objekt
fatal: index-pack fehlgeschlagen
[tom1@achse /data/tomsData/github]$ git --version
git version 2.11.1
[tom1@achse /data/tomsData/github]$ uname -a
Linux achse 4.9.8-1-ARCH #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017 x86_64 GNU/Linux
no subdir hub was created
Setting
[transfer]
fsckObjects = false
in your .gitconfig is a workaround. Clone works now.
Thanks for sharing your workaround.
Your issue doesn't seem to be related to this project, which is called "hub" and is a command-line wrapper around git. You seem to be using git directly.
Yes i use vanilla git ... to clone the hub repo and this cloning fails so i suspect an inconsistency in the hub repo, not a problem with the hub application or code. My idea is to thoroughly check the hub repo
[tom1@achse /data/tomsData/github]$ env LANG=en_us.utf8 git clone https://github.com/github/hub.git
Cloning into 'hub'...
remote: Counting objects: 13748, done.
remote: Compressing objects: 100% (84/84), done.
error: object 9ef2af57366f63deb751b92a8ca630fe598b10f0: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed
[tom1@achse /data/tomsData/github]$ git --version
git version 2.11.1
[tom1@achse /data/tomsData/github]$ uname -a
Linux achse 4.9.8-1-ARCH #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017 x86_64 GNU/Linux
Cloning with --depth 1 works
$ env LANG=en_us.utf8 git clone --depth 1 https://github.com/github/hub.git
Cloning into 'hub'...
remote: Counting objects: 472, done.
remote: Compressing objects: 100% (404/404), done.
remote: Total 472 (delta 27), reused 252 (delta 20), pack-reused 0
Receiving objects: 100% (472/472), 368.91 KiB | 404.00 KiB/s, done.
Resolving deltas: 100% (27/27), done.
Ah, my apologies: I wasn't reading closely and didn't realize that you were trying to clone this very repository and had problems with it.
I just ran health checks on this repository and didn't find any problems. I also tried cloning it from a Linux machine, but there was no problems. Is your problem reproducible every time? Do you have any other systems that this happens on, or is localized to just your version of Arch linux + that version of git?
Is it an option for you to turn this warning off with git config --global fsck.zeroPaddedFilemode ignore
?
I'm seeing this error on MacOS Sierra. It happens with the same commit ID and I checked it multiple times.
> hub clone [email protected]:github/hub.git
Cloning into 'hub'...
remote: Counting objects: 13748, done.
error: object 9ef2af57366f63deb751b92a8ca630fe598b10f0: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed
Adding the following doesn't stop avoid the error (which is not hub
's problem, per se).
[fsck]
zeroPaddedFilemode = ignore
I can confirm this is a problem with the repo, I tried both on a Linux machine (with git 2.7.4) and on OS X (with git 2.12.2). To reproduce:
git clone --config transfer.fsckObjects=true https://github.com/github/hub
The result is:
Cloning into 'hub'...
remote: Counting objects: 13913, done.
remote: Compressing objects: 100% (3/3), done.
error: object 9ef2af57366f63deb751b92a8ca630fe598b10f0: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
Unfortunately, the only way to really fix the problem appears to be to export the repo and then re-import it, which would rewrite history. If you don't want to rewrite history then it should be pointed out that anyone that has globally turned on fsckObjects should know how to turn it off temporarily if they need to clone a repo that has problems that fsckObjects will fail on. In this case the answer is:
git clone --config transfer.fsckObjects=false https://github.com/github/hub
FWIW, if you are cloning under Debian you'll need to pass all three fsckobjects=false while cloning (see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813157), namely git clone --config transfer.fsckobjects=false --config receive.fsckobjects=false --config fetch.fsckobjects=false
. Using only transfer.fsckobjects
didn't work for me on Debian Stretch (git 2.11.0)
Still considered corrupt by git 2.14.2:
~/src $ git clone https://github.com/github/hub.git
Cloning into 'hub'...
remote: Counting objects: 14216, done.
error: object 9ef2af57366f63deb751b92a8ca630fe598b10f0: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed
~/src $ git --version
git version 2.14.2
This is still an issue.
This is still an issue.
+1
This also breaks go get github.com/github/hub
. Might have to actually do a full export/import and rewrite history. The sooner the better?
Adding the following doesn't stop avoid the error (which is not
hub
's problem, per se).[fsck] zeroPaddedFilemode = ignore
From what I can tell, this needs git version 2.19.0+, and an additional config item:
[fetch "fsck"]
zeroPaddedFilemode = ignore
* The test performed at the receiving end of "git push" to prevent bad objects from entering repository can be customized via receive.fsck.* configuration variables; we now have gained a counterpart to do the same on the "git fetch" side, with fetch.fsck.* configuration variables.
https://git-scm.com/docs/git-config#Documentation/git-config.txt-fsckltmsg-idgt:
Unlike variables like
color.ui
andcore.editor
the
receive.fsck.<msg-id>
andfetch.fsck.<msg-id>
variables will not
fall back on thefsck.<msg-id>
configuration if they aren鈥檛 set. To
uniformly configure the same fsck settings in different circumstances
all three of them they must all set to the same values.
Most helpful comment
I can confirm this is a problem with the repo, I tried both on a Linux machine (with git 2.7.4) and on OS X (with git 2.12.2). To reproduce:
The result is:
Unfortunately, the only way to really fix the problem appears to be to export the repo and then re-import it, which would rewrite history. If you don't want to rewrite history then it should be pointed out that anyone that has globally turned on fsckObjects should know how to turn it off temporarily if they need to clone a repo that has problems that fsckObjects will fail on. In this case the answer is: