git clone fails with zeroPaddedFilemode error

[akalin]

When I do a git clone I get:

> git clone https://github.com/defunkt/coffee-mode.git
Cloning into 'coffee-mode'...
remote: Counting objects: 1828, done.
error: object 2699d230e3b592ae42506d7b5c969a7ac6a4593c: zeroPaddedFilemode: contains zero-padded file modes
fatal: Error in object
fatal: index-pack failed

There's a workaround described here ( mislav/hub#1404 ) but it's probably better to fix the underlying problem, as described on: https://stackoverflow.com/questions/14700502/how-to-fix-git-zero-padded-file-modes-warning/14839059#14839059

I did the fix with an existing local repository and pushed it to my fork: https://github.com/akalin/coffee-mode . The downside is that it changes a lot of refs, though.

NB: I had to create an empty repo instead of forking, as simply forking and the re-pushing left the old (corrupt) commits in place.

[skangas]

Any chance we could get this fixed?

We are considering using a shallow branch for the coffee-mode package in NonGNU ELPA to avoid this error. Unfortunately, it's less nice as it doesn't preserve the full git history (attribution, etc.). See: https://debbugs.gnu.org/65241

[syohex]

I suppose this issue cannot be fixed without changing all commit histories. I suppose it is difficult or imposibble. Can you add following git configurations temporary when cloning this repo ?

git config --global fsck.zeroPaddedFilemode ignore
git config --global fetch.fsck.zeroPaddedFilemode ignore
git config --global receive.fsck.zeroPaddedFilemode ignore

[skangas]

I suppose this issue cannot be fixed without changing all commit histories. I suppose it is difficult or imposibble. Can you add following git configurations temporary when cloning this repo ?

This affects more than coffee-mode, since NonGNU ELPA pulls in the entire history of the project when we add a package. Currently, every user that checks out the NonGNU ELPA git repository has to use this workaround, and it seems like it confuses people. (See the bug report linked above.)

I personally think it would be better to rewrite the git history, despite the drawbacks, than having all users do continue having to use this workaround. The other alternative we came up with is using a shallow branch on NonGNU ELPA, but sadly that will lose some of the history, including attribution.

I think it's up to you which of these two things you find less desirable, but it would be less work for us if you rewrote history to remove the offending commit.

[syohex]

Can you use a forked repository that rewrites the histories correctly ? I'm just a collaborator of this repository so I cannot decide whether I should rewrite histories of this repository. (For example, if someone uses this repository as submodule, then it might not work by rewriting histories)

This repository is no longer maintained and I suppose most of people don't use CoffeeScript anymore(Use TypeScript or JavaScript instead). I think coffee-mode.el will not be updated in the future. So I suppose there are no problems if you use the forked repo.

[skangas]

Thanks. Based on the above, I will propose that NonGNU ELPA moves ahead with a shallow git branch.