diff options
author | Jeff King <peff@peff.net> | 2014-12-15 18:21:57 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2014-12-17 11:04:45 -0800 |
commit | a18fcc9ff22b714e7df30c400c05542f52830eb0 (patch) | |
tree | 09c9eeb90413583fe4e862d34c1308f7ce94bb8c /path.c | |
parent | a42643aa8d88a2278acad2da6bc702e426476e9b (diff) | |
download | git-a18fcc9ff22b714e7df30c400c05542f52830eb0.tar.gz |
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>
Diffstat (limited to 'path.c')
0 files changed, 0 insertions, 0 deletions