Simon Josefsson <si...@josefsson.org> writes: > I have had that settings in my .gitconfig for several years, and the > number of git repositories that fail to clone with it is not negligible. > I encourage people to enable it and experiment for themselves. Try > https://git.savannah.gnu.org/git/coreutils.git for example. I hack > around it by adding a 'fclone' alias, and I still need to use it once in > a while.
> [transfer] > fsckObjects = true > [alias] > fclone = clone -c "fetch.fsckObjects=false" I've been using this setting for over four years (I think maybe about six years) and have never had a failure before this email message, just to add another data point. It may depend on whether you work with a lot of Git repositories from very early adopters. I started using this setting when I discovered a Git repository at work that had become silently corrupted due to disk or memory corruption and went undetected for a disturbing length of time. I agree that the coreutils repository does fail: error: object a6727941433ee1c91a20ede6cb381af1d18c566d: missingSpaceBeforeDate: invalid author/committer line - missing space before date (That also confirms my suspicion that if you set this Git configuration setting, git clone will fail if it detects any invalid objects.) I don't know if there is a setting that disables the checks for more pendatic issues such as malformed author/committer lines but retains the verification of object hashes. > Maybe the number of repositories on Salsa with this problem is low, but > isn't the tag2upload design vulnerable to upstream git repositories > having this problem too? I think it would be fine for tag2upload to refuse to work on repositories that cannot pass git fsck. I know there are some good reasons why people decline to fix old repositories with things that Git considers to be corruption, but tag2upload is not intended to be universal and is strictly optional and already doesn't support some things that people may wish to do. This feels like a reasonable one to add to that list, to me. The alternative would be to add some sort of support for fsck.skipList, but that seems like annoying and arguably unnecessary complexity that potentially reintroduces the same security problem via a different route. Or, of course, find a way to disable the author/committer checks, which I suspect are most of the failures, and keep the object hash checks. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
