summaryrefslogtreecommitdiff
path: root/builtin/grep.c
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2018-07-13 15:39:53 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-07-16 10:57:22 -0700
commit0d68764d94958aece0355d5d27f383e7d4de2e58 (patch)
tree3eacc406bd62482325429497bfd743e2e486697f /builtin/grep.c
parentfsck: silence stderr when parsing .gitmodules (diff)
downloadtgif-0d68764d94958aece0355d5d27f383e7d4de2e58.tar.xz
fsck: split ".gitmodules too large" error from parse failure
Since ed8b10f631 (fsck: check .gitmodules content, 2018-05-02), we'll report a gitmodulesParse error for two conditions: - a .gitmodules entry is not syntactically valid - a .gitmodules entry is larger than core.bigFileThreshold with the intent that we can detect malicious files and protect downstream clients. E.g., from the issue in 0383bbb901 (submodule-config: verify submodule names as paths, 2018-04-30). But these conditions are actually quite different with respect to that bug: - a syntactically invalid file cannot trigger the problem, as the victim would barf before hitting the problematic code - a too-big .gitmodules _can_ trigger the problem. Even though it is obviously silly to have a 500MB .gitmodules file, the submodule code will happily parse it if you have enough memory. So it may be reasonable to configure their severity separately. Let's add a new class for the "too large" case to allow that. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/grep.c')
0 files changed, 0 insertions, 0 deletions