New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git clone ends ... contains zero-padded file modes #1404
Comments
Setting 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
|
Cloning with --depth 1 works
|
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 |
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
|
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:
|
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 |
Still considered corrupt by git 2.14.2:
|
This is still an issue. |
See mislav#1404 for more information
+1 This also breaks |
From what I can tell, this needs git version 2.19.0+, and an additional config item:
https://git-scm.com/docs/git-config#Documentation/git-config.txt-fsckltmsg-idgt:
|
[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
The text was updated successfully, but these errors were encountered: