Corruption in the git tree

[ghost]

Hello, I've just noted corruption in the git tree, preventing me from pushing to my mirror repo:

% git push     
Everything up-to-date
Counting objects: 27900, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (6746/6746), done.
Writing objects: 100% (27900/27900), 2.80 MiB | 2.38 MiB/s, done.
Total 27900 (delta 20215), reused 27298 (delta 19731)
remote: error: object 33c562f060b2ba7e8c82c2c2420d4f29196f05ae:contains zero-padded file modes
remote: fatal: Error in object
error: unpack failed: index-pack abnormal exit
To git@gitlab.com:korobkov/active_scaffold.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'git@gitlab.com:korobkov/active_scaffold.git'

When I checked fresh clone from your github repo, I saw the same problem with zero-padded file modes:

% git clone https://github.com/activescaffold/active_scaffold.git
% cd active_scaffold
% git fsck
Checking object directories: 100% (256/256), done.
warning in tree 33c562f060b2ba7e8c82c2c2420d4f29196f05ae: contains zero-padded file modes
warning in tree 9345f91e4c8295c06a776f197b53e021d306620c: contains zero-padded file modes
warning in tree 9ac8b229cc79bec6dd5729ce76b25c637959b52e: contains zero-padded file modes
Checking objects: 100% (29785/29785), done.

The first problem is that this corruption affects your own repo and all the clones (see https://stackoverflow.com/questions/15598465/should-i-worry-about-git-fsck-warning-contains-zero-padded-file-modes).

The other problem is that as those bad objects are going to me from upstream (your repo), so I'll receive them again after pulling. Also after fixing all commits have totally different hashes, so I couldn't be able to propose any comments in your upstream… :(

I've already found a working solution there: https://stackoverflow.com/questions/14700502/how-to-fix-git-zero-padded-file-modes-warning , which helped me to fix my fork repo.

Could you, please, fix your repo with git fast-export --all and consequent git fast-import, and re-push it to github?

[scambra]

so weird, I don't get any error when I push However, fixing main repo with fast-export and fast-import will change hashes for all commits, which will break every clone

[ghost]

On Tue, 24 Feb 2015 06:27:12 -0800 Sergio Cambra notifications@github.com wrote:

so weird, I don't get any error when I push

I think it's github, which behaves tolerantly to corruptions in repos, while gitlab works more strictly following consistency rules, actually protecting other devs from unintentionally cloning corrupted repo and propagating those nasty things to the next level clones, which in the global scale seems to force you as a main repo maintainer to insist on backward compatibility even with corruptions in git repo… :(

However, fixing main repo with fast-export and fast-import will change hashes for all commits, which will break every clone

«I'm sad to hear it», as Richard Stallman could say [1]. :( They are already corrupted in terms of git fsck. But you are right that no one could be able to fast-forward. While I myself think it's not a problem at all, as they could easiliy do git pull --rebase or even re-clone from scratch, (it's just a matter of seconds), I could understand you could have your own reasons for not doing so. It could be only your decision, not mine. I even think you like me want to see the repo fully consistent, without even smalliest warning, not to say error, while some external circumstanes could make you think and do another way.

In any case, I'll respect your choice and won't push on this issue by asking more about fixing it, should you decide to leave it all as is. In that case this issue may still be of some use just for documenting such repo incosistenices, which may lead to problems with pushing to mirrors other than github in the future…

[1] http://edward.oconnor.cx/2005/04/rms

[ghost]

P.S. Most end users/customers likely use ActiveScaffold as a gem, rather than git tree clone, so they'll hardly notice any difference in commit hashes… ;-) How do you think?

[scambra]

fixed, although it can break people using github on Gemfile directly (instead of installing gem versions), bundle install and bundle update will fail if Gemfile.lock is not regenerated, or activescaffold removed from Gemfile.lock.

[ghost]

Wonderful!! Muchas gracias, Sergio! :) :) You've decided to fix it! What's you new master branch tip hash? (I still have same fsck issue with 569b0584700b9e229bcc3dfcf5c5472254032874)…

[scambra]

That's HEAD. I have same fsck issue, I don't understand

I run git fast-export --all | ( cd ../active_scaffold2 && git fast-import ) Then setup remote on active_scaffold2 and git push -f origin master git fsck was right on active_scaffold2 but if I clone again, wrong commits are there.

[scambra]

I think I fixed, I had to force pushing tags again

[ghost]

Thank you very much again! :) I'm really happy now! :) :) The repo is pretty clear and consistent. All is well and seems to going better and better with time passing… My new gitlab clone (https://gitlab.com/korobkov/active_scaffold) works very well. And I'm particularly grateful to you for being responsive to my wish, even it wasn't an easy decision for you. :)