summaryrefslogtreecommitdiff
path: root/t/t1507-rev-parse-upstream.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2014-12-15 18:21:57 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2014-12-17 11:04:45 -0800
commita18fcc9ff22b714e7df30c400c05542f52830eb0 (patch)
tree09c9eeb90413583fe4e862d34c1308f7ce94bb8c /t/t1507-rev-parse-upstream.sh
parentread-cache: optionally disallow HFS+ .git variants (diff)
downloadtgif-a18fcc9ff22b714e7df30c400c05542f52830eb0.tar.xz
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 't/t1507-rev-parse-upstream.sh')
0 files changed, 0 insertions, 0 deletions