Cloning fails due to zero-padded file modes

[mediafinger]

I tried to clone the project but it does always fails. There seems to be an issue with the integrity of the git repo.

I also tried forking it (worked) and then cloning it (same issue).

$> git clone git@github.com:sinatra/sinatra.git
Cloning into 'sinatra'...
remote: Counting objects: 19910, done.
error: object 218b8c8019a785b8c08c1dd64beff68af63cc1f9: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

[b264]

I just tried it and it did work.

devbox@ubuntu-server-xenial:~/code$ git --version
git version 2.7.4
devbox@ubuntu-server-xenial:~/code$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial
devbox@ubuntu-server-xenial:~/code$ git clone git@github.com:sinatra/sinatra.git
Cloning into 'sinatra'...
Host key fingerprint is SHA256:n6E5SYUpJ7E1IGOCspRoThXkTxdCKGlwmARLviWbg68
+---[RSA 2048]----+
| =+o...+=o..     |
|o++... *o .      |
|*.o.  *o.        |
|oo.  ..o.= .     |
|.+o. .. S =      |
|*=+ .  o = .     |
|OE .  . o        |
| o     .         |
|                 |
+----[SHA256]-----+
remote: Counting objects: 19910, done.
remote: Total 19910 (delta 0), reused 0 (delta 0), pack-reused 19910
Receiving objects: 100% (19910/19910), 5.92 MiB | 0 bytes/s, done.
Resolving deltas: 100% (10750/10750), done.
Checking connectivity... done.
devbox@ubuntu-server-xenial:~/code$ 

[b264]

What version of git are you using?

[mediafinger]

git version 2.13.0 on macOS Sierra

(just tried again, still the same issue)

[mediafinger]

In my .gitconfig I have the setting:

[transfer]
  fsckobjects = true

When I change this to false I can clone the repo. Running git fsck yields following results:

$> git fsck
Checking object directories: 100% (256/256), done.
warning in tree 218b8c8019a785b8c08c1dd64beff68af63cc1f9: zeroPaddedFilemode: contains zero-padded file modes
warning in tree 496479ab009c76d3d5e5b5eb8f05e478555b730a: zeroPaddedFilemode: contains zero-padded file modes
warning in tree 6720ac897243912cf384731c42a6ed4005bc384c: zeroPaddedFilemode: contains zero-padded file modes
Checking objects: 100% (19910/19910), done.

In case one of the maintainers is interested in fixing this, maybe this contains some hints:
https://git.wiki.kernel.org/index.php/GitFaq#How_to_fix_a_broken_repository.3F

[b264]

Yes, it is showing as corrupt for me as well. Why does git not default to fsckobjects I wonder ...

[zzak]

fsck my life

[rohitpaulk]

Looks like this was first encountered in #532 (2012!).

I was able to fix it by following the steps in this StackOverflow answer. However, this ends up rewriting a huge chunk of the repo's history, since the broken SHAs are pretty old.

I also had to convert a bunch of signed tags to unsigned, because of the SHA changes.

Here's the updated repository: https://github.com/rohitpaulk/sinatra-gitfsck

The steps I took were:

• Clone this repository
• Make a directory for the new repository, run git init
• From within the old repository:

git fast-export --all --signed-tags=warn-strip | (cd ../new-sinatra && git fast-import)

Other instances of this in the wild:

• fsck fails on git repo clj-commons/aleph#327
• git clone ends ... contains zero-padded file modes mislav/hub#1404
• https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1602
• zero padded filemode in your git history holman/dotfiles#231
• Git repository is corrupt fabricjs/fabric.js#3430

One possible cause for this bug is in Grit, that was fixed a long time ago.

[dentarg]

Additional instances of this in the wild:

• Zero-padded file modes in repository  pallets/flask#2029 – no rewrite, added documentation
• repo fails git fsck jashkenas/underscore#2887 – leaning towards documenting it
• git clone fails with transfer.fsckobjects = true: zeroPaddedFilemode ohmyzsh/ohmyzsh#4963 – no rewrite
• Git fsck failing redis/redis#489 – no rewrite
• zeroPaddedFilemode: contains zero-padded file modes ruby-llvm/ruby-llvm#72 – new issue, no discussion yet

Seeing there hasn't been any activity in this issue since Oct 2017, I guess the issue isn't affecting that many Sinatra users? I think Sinatra too should address it with documentation instead of rewriting the git history.

[zzak]

I agree, and going to close this ticket until someone can introduce a solution that doesn't involve rewriting the entire git history (including signed commits).