You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The least invasive option would be to just disable the check by setting fsck.gitmodulesUrl to warn or ignore. This works great locally, but unfortunately, there is no way to configure this in a way that automatically gets applied when creating a new clone for this specific repo. There are ways to make this work by changing the global git config of the GitLab instance as an administrator, but it is unlikely that we can persuade all relevant instances to make this change.
Instead, the only option I can see is to do a ten-year history rewrite. :(
The flag day will be painful, but instead of just force-pushing main and causing mayhem, we might be able to do this more smoothly:
Create a main-fsck branch, which does not contain the faulty submodule state.
Rename main to main-pre-fsck. GitHub has decent functionality for dealing with renaming the main branch, as far as I know.
Make main-fsck the new default branch. GitHub also has decent functionality for this.
Rename main-fsck to main.
There should be at least six weeks between each of the steps to allow local clones of active contributors to adjust and feedback to arrive.
Rewriting history
Rewriting history is done best via git filter-repo. Since we are forced to rewrite history, we might as well purge LFS from the new branch's history, which makes pushing to GitLab even easier. Additionally, we can go ahead and remove a few binary files and large, generated files. They are described in more detail in the next section.
Warning
Always start rewriting from a fresh repo, if you want to try this yourself.
At the end, git filter-repo --analyze reports the following statistics on a repo containing only main-fsck:
== Overall Statistics ==
Number of commits: 8541
Number of filenames: 1300
Number of directories: 185
Number of file extensions: 39
Total unpacked size (bytes): 218742593
Total packed size (bytes): 7473231
For reference, this is the report on the current repo, without main-fsck:
== Overall Statistics ==
Number of commits: 11783
Number of filenames: 1340
Number of directories: 188
Number of file extensions: 47
Total unpacked size (bytes): 280252014
Total packed size (bytes): 51589333
This is the report on the current repo, with main-fsck:
== Overall Statistics ==
Number of commits: 20150
Number of filenames: 1340
Number of directories: 188
Number of file extensions: 47
Total unpacked size (bytes): 280252014
Total packed size (bytes): 51590289
Note that the size of the full repo will not get smaller, even after fully migrating to main-fsck. This is because we need to keep the old main-pre-fsck around forever to keep tags and references to specific commits working. The size benefit will come to all clones who only clone main-fsck with --single-branch, though.
Most importantly, though, this now completes successfully:
Before pushing main-fsck to the main repo, I would like to gather feedback on the files filtered out of the branch history. Should we filter out more files? Should we filter out fewer files? I'd like to avoid pushing a history-rewritten branch more than once, since this causes explosions in the number of overall commits in the repository.
History
There was an even worse force-push back in February 2021 with histories that don't share a root commit (v0.3.48..v0.3.49, GitHub comparison):
Issue
Running
git clone https://github.com/hermit-os/kernel.git cd kernel git fsckresults in
with exit code 4.
This happens since git 2.44.0, released Feb 2024, more specifically since git-scm/git@
8430b43.On the Hermit side, this is caused by c1c6a1a in 2016. It was resolved four minutes later in db6e997.
On its own, this is fine. You can still clone the repo locally and on GitHub. However, you cannot create a new repo any more on:
This is quite unfortunate, and we would like to make this repo work on those instances.
There are two troubleshooting pages for GitLab:
Options
The least invasive option would be to just disable the check by setting
fsck.gitmodulesUrltowarnorignore. This works great locally, but unfortunately, there is no way to configure this in a way that automatically gets applied when creating a new clone for this specific repo. There are ways to make this work by changing the global git config of the GitLab instance as an administrator, but it is unlikely that we can persuade all relevant instances to make this change.Instead, the only option I can see is to do a ten-year history rewrite. :(
The flag day will be painful, but instead of just force-pushing
mainand causing mayhem, we might be able to do this more smoothly:main-fsckbranch, which does not contain the faulty submodule state.maintomain-pre-fsck. GitHub has decent functionality for dealing with renaming the main branch, as far as I know.main-fsckthe new default branch. GitHub also has decent functionality for this.main-fscktomain.There should be at least six weeks between each of the steps to allow local clones of active contributors to adjust and feedback to arrive.
Rewriting history
Rewriting history is done best via git filter-repo. Since we are forced to rewrite history, we might as well purge LFS from the new branch's history, which makes pushing to GitLab even easier. Additionally, we can go ahead and remove a few binary files and large, generated files. They are described in more detail in the next section.
Warning
Always start rewriting from a fresh repo, if you want to try this yourself.
remove-from-history.txt:filter-kernel.shResults
Repository size according to GitLab when only pushing
main-fsck:At the end,
git filter-repo --analyzereports the following statistics on a repo containing onlymain-fsck:For reference, this is the report on the current repo, without
main-fsck:This is the report on the current repo, with
main-fsck:Note that the size of the full repo will not get smaller, even after fully migrating to
main-fsck. This is because we need to keep the oldmain-pre-fsckaround forever to keep tags and references to specific commits working. The size benefit will come to all clones who only clonemain-fsckwith--single-branch, though.Most importantly, though, this now completes successfully:
git fsck --unreachable \ --dangling \ --tags \ --root \ --cache \ --reflogs \ --full \ --strict \ --lost-found \ --progress \ --name-objects \ --referencesStatus
Before pushing
main-fsckto the main repo, I would like to gather feedback on the files filtered out of the branch history. Should we filter out more files? Should we filter out fewer files? I'd like to avoid pushing a history-rewritten branch more than once, since this causes explosions in the number of overall commits in the repository.History
There was an even worse force-push back in February 2021 with histories that don't share a root commit (v0.3.48..v0.3.49, GitHub comparison):
Rebasing feature branches
Rebasing is surprisingly easy. To rebase a feature branch from
main-pre-fsckontomain-fsck, just run:For details, see RECOVERING FROM UPSTREAM REBASE (the hard case).