Skip to content

Fix git repository corruption #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
alerque opened this issue Apr 1, 2019 · 4 comments
Closed

Fix git repository corruption #5

alerque opened this issue Apr 1, 2019 · 4 comments

Comments

@alerque
Copy link
Member

alerque commented Apr 1, 2019

This repository has had a long standing issue with an invalid object in a commit. If git option for fsckObjects is set to true, the repository cannot be cloned:

❯ git clone git@github.com:vim-pandoc/vim-markdownfootnotes.git
Cloning into 'vim-markdownfootnotes'...
remote: Enumerating objects: 61, done.
error: object 03bd5b16bcd2add179d28dfb7252384770082880: badTimezone: invalid author/committer line - bad time zone
fatal: fsck error in packed object
fatal: index-pack failed

For years I've worked around this by temporarily disabling this setting in my user's git-config, cloning the repository, then turning the setting back on. In my bootstrap scripts I pass extra arguments to git for this project in particular that none of my other clones require.

Unfortunately since this was not caught and fixed by running git fsck early, fixing it is hard. Or at least awkward. There are actually two objects that need fixing:

❯ git fsck
Checking object directories: 100% (256/256), done.
error in commit 03bd5b16bcd2add179d28dfb7252384770082880: badTimezone: invalid author/committer line - bad time zone
error in commit 7d48d84e93060e1b5aa05fdcdc782690e7d3801e: badTimezone: invalid author/committer line - bad time zone
Checking objects: 100% (61/61), done.

These are of course the initial 2 commits in this repository. Fixing them means rebasing all the other commits. This will mean everybody's clones will also need rebasing.

I would suggest that this is worth doing, and doing sooner rather than later. However since it is a bit of a disruptive change I will hold off actually doing it until there is some consensus that this is okay.

Alternatives to rebasing this would be to rename this repository as a "legacy" repo and open a new one that is not a fork of this one and post the clean branch there. I don't support this option, but it's the only other way I can think of to deal with the problem.

Lastly doing noting and just letting all future cloners deal with this in their own way is an option. Again I don't support this because it's so disruptive to anybody that has integrity checks turned on, but it is an option.

@fmoralesc
Copy link
Member

fmoralesc commented Apr 1, 2019 via email

@alerque
Copy link
Member Author

alerque commented Apr 1, 2019

Sounds fair to me. See this commit for the warning I added.

@fmoralesc
Copy link
Member

fmoralesc commented Apr 1, 2019 via email

@alerque
Copy link
Member Author

alerque commented Apr 16, 2019

The entire repository was rebased to correct the two invalid commits. See the README for details on how to update clones.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants