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 git@github.com: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

https://github.com/git/git/blob/1d4361b0f344188ab5eec6dcea01f61a3a3a1670/Documentation/RelNotes/2.19.0.txt#L68-L72

 * 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 and core.editor the
receive.fsck.<msg-id> and fetch.fsck.<msg-id> variables will not
fall back on the fsck.<msg-id> configuration if they aren’t set. To
uniformly configure the same fsck settings in different circumstances
all three of them they must all set to the same values.