]> git.ipfire.org Git - thirdparty/git.git/commit - fsck.c
fsck: complain about HFS+ ".git" aliases in trees
authorJeff King <peff@peff.net>
Mon, 15 Dec 2014 23:21:57 +0000 (18:21 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 17 Dec 2014 19:04:45 +0000 (11:04 -0800)
commita18fcc9ff22b714e7df30c400c05542f52830eb0
tree09c9eeb90413583fe4e862d34c1308f7ce94bb8c
parenta42643aa8d88a2278acad2da6bc702e426476e9b
fsck: complain about HFS+ ".git" aliases in trees

Now that the index can block pathnames that case-fold to
".git" on HFS+, it would be helpful for fsck to notice such
problematic paths. This lets servers which use
receive.fsckObjects block them before the damage spreads.

Note that the fsck check is always on, even for systems
without core.protectHFS set. This is technically more
restrictive than we need to be, as a set of users on ext4
could happily use these odd filenames without caring about
HFS+.

However, on balance, it's helpful for all servers to block
these (because the paths can be used for mischief, and
servers which bother to fsck would want to stop the spread
whether they are on HFS+ themselves or not), and hardly
anybody will be affected (because the blocked names are
variants of .git with invisible Unicode code-points mixed
in, meaning mischief is almost certainly what the tree
author had in mind).

Ideally these would be controlled by a separate
"fsck.protectHFS" flag. However, it would be much nicer to
be able to enable/disable _any_ fsck flag individually, and
any scheme we choose should match such a system. Given the
likelihood of anybody using such a path in practice, it is
not unreasonable to wait until such a system materializes.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fsck.c
t/t1450-fsck.sh