Open rmloveland opened 8 years ago
Luckily git clone --depth 1
works.
I've enabled the same settings as you have, and cloned fine without any problem, both via HTTPS and ssh. So I'd guess this is either a problem with your git version or the network.
Wait, I cloned the wrong repo, my bad. I can reproduce it.
If someone with commit access wants to fix the problem, here is a fix:
$ cd /tmp/
$ git clone -c fetch.fsckObjects=false https://github.com/Raku/raku.org.git
$ git init raku.org-fixed
$ cd raku.org
$ git fast-export --all | (cd ../raku.org-fixed && git fast-import)
$ find . -type f ! -path '*/.git/*' -exec sha256sum "{}" + > /tmp/sha256sum.txt
$ cd ../raku.org-fixed
$ git checkout
$ sha256sum --quiet -c /tmp/sha256sum.txt
And then you need to force push the repository.
Works on Linux. The find command ignores the .git
directory because the SHAs of the repository have changed.
You're going to lose all the external links to the old IDs and the 3 pull requests will be broken but the error is very annoying. And disabling the fsck to clone a repo is never a good idea or the right solution to the problem.
Difficult to come to a decision here. Any git experts with deeper insights of the tradeoffs?
I thought I had already tagged @dontlaugh here.
I can't reproduce this on my btrfs filesystem. I've asked some friends to try the clone to try and reproduce.
Here are the settings in my
~/.gitconfig
that I believe are causing git to catch these issues: