Ignore fsck / zero-padded file mode errors in "git clone"

Question

I have the following settings in my global Git configuration:

[transfer]
    fsckobjects = true

[fetch]
    fsckobjects = true

[receive]
    fsckobjects = true

These verify that all objects in the cloned database are valid and reachable.

However, some repos I want to check out have errors, like oh-my-zsh:

git clone https://github.com/robbyrussell/oh-my-zsh.git .oh-my-zsh 
Cloning into '.oh-my-zsh'...
remote: Counting objects: 15624, done.
error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

Is there a way I can override my global fsckobjects settings for a single "git clone" operation?

Slaughter

With Git 2.19 (Q3 2018), you will be able to ignore that error, with git -c fetch.fsckobjects=true -c fetch.fsck.unterminatedheader=warn clone https://github.com/robbyrussell/oh-my-zsh.git .oh-my-zsh. See my answer below. – Snipe

Answer 1

Use git clone --config key=value and pass all of the arguments you want to skip there. For oh-my-zsh, that looks like this:

git clone --config transfer.fsckobjects=false \
    --config receive.fsckobjects=false \
    --config fetch.fsckobjects=false \
    git://github.com/robbyrussell/oh-my-zsh.git

Slaughter

Answer 2

Git 2.19 (Q3 2018) will now allow to get past that error (transformed as a warning).

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.

See commit 8a6d052, commit 65a836f, commit d786da1, commit 1362df0, commit 8b55b9d, commit 720dae5, commit 456bab8, commit b2558ab, commit 5180dd2, commit 95d9d4b (27 Jul 2018) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit f8ca718, 17 Aug 2018)}

fetch: implement fetch.fsck.*

Implement support for fetch.fsck.* corresponding with the existing receive.fsck.*. This allows for pedantically cloning repositories with specific issues without turning off fetch.fsckObjects.

One such repository is https://github.com/robbyrussell/oh-my-zsh.git which before this change will emit this error when cloned with fetch.fsckObjects:

error: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

Now with fetch.fsck.zeroPaddedFilemode=warn we'll warn about that issue, but the clone will succeed:

warning: object 2b7227859263b6aabcc28355b0b994995b7148b6: zeroPaddedFilemode: contains zero-padded file modes
warning: object a18c4d13c2a5fa2d4ecd5346c50e119b999b807d: zeroPaddedFilemode: contains zero-padded file modes
warning: object 84df066176c8da3fd59b13731a86d90f4f1e5c9d: zeroPaddedFilemode: contains zero-padded file modes

The motivation for this is to be able to turn on fetch.fsckObjects globally across a fleet of computers but still be able to manually clone various legacy repositories by either white-listing specific issues, or better yet whitelist specific objects.

Snipe

Answer 3

If you just need the latest version – such as for automated installs – I have been using this in my scripts (for example):

git clone --depth 1 https://github.com/ohmyzsh/ohmyzsh

It does not clone the whole repo history, just the latest version, which should be ok anyway for automated installs.

(I am quite sure I did not come up with this myself, but I am unable to retrace it to the original source).

Devour