On Mon, Jul 29, 2019 at 09:58:52AM +0200, Olivier Bornet wrote: > I have a git repository with an error in a submodule path in the history. > The submodule path is “-f”, which is not allowed. But for some reason, it’s in the history of the git, and I’m trying to find a way to manage it without having to rewrite the full history on the main gitlab (if possible)... > > To reproduce this unwanted history: > After that, even if the git is working correctly, we have a “bad” history if we check with fsck: > > $ git fsck > Checking object directories: 100% (256/256), done. > error in blob 19a97d3b70760c74b780c8134e33f5392292c2e6: gitmodulesPath: disallowed submodule path: -f > > Is it possible to correct it? Must git handle this kind of errors? To correct without rewriting history, no. However, you can tell 'git fsck' to ignore it using the 'fsck.skipList' configuration variable (see 'git help config'; for some reason it's not included in 'git fsck's documentation): $ cat <<EOF >.git-fsck-skiplist > # invalid submodule path > 19a97d3b70760c74b780c8134e33f5392292c2e6 > EOF $ git config fsck.skipList .git-fsck-skiplist $ git fsck Checking object directories: 100% (256/256), done. It may or may not be worth committing this file, I'm not quite sure what the best practice is. By committing it others don't have to maintain such a skiplist file themselves, though they still have to set the config variable. OTOH, if anyone sets this config variable and attempts to run 'git fsck' while on a branch that doesn't contain this file, then they will get a 'fatal: could not open object name list: .git-fsck-skiplist' error. And it won't help anyone cloning the repository with 'fetch.fsckObjects' enabled.
