]> git.ipfire.org Git - thirdparty/git.git/commit - fsck.h
fsck: downgrade tree badFilemode to "info"
authorJeff King <peff@peff.net>
Wed, 10 Aug 2022 21:04:07 +0000 (17:04 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 10 Aug 2022 21:26:29 +0000 (14:26 -0700)
commit4dd3b045f528b8d9cbbb4a50e371affb0543f37d
tree0c70bb0d528e9176a3537ace509eb4a2b947decb
parent53602a937dc9eacd67b6afcd781f7b15bb02682f
fsck: downgrade tree badFilemode to "info"

The previous commit un-broke the "badFileMode" check; before then it was
literally testing nothing. And as far as I can tell, it has been so
since the very initial version of fsck.

The current severity of "badFileMode" is just "warning". But in the
--strict mode used by transfer.fsckObjects, that is elevated to an
error. This will potentially cause hassle for users, because historical
objects with bad modes will suddenly start causing pushes to many server
operators to be rejected.

At the same time, these bogus modes aren't actually a big risk. Because
we canonicalize them everywhere besides fsck, they can't cause too much
mischief in the real world. The worst thing you can do is end up with
two almost-identical trees that have different hashes but are
interpreted the same. That will generally cause things to be inefficient
rather than wrong, and is a bug somebody working on a Git implementation
would want to fix, but probably not worth inconveniencing users by
refusing to push or fetch.

So let's downgrade this to "info" by default, which is our setting for
"mention this when fscking, but don't ever reject, even under strict
mode". If somebody really wants to be paranoid, they can still adjust
the level using config.

Suggested-by: Xavier Morel <xavier.morel@masklinn.net>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck.h
t/t5504-fetch-receive-strict.sh