summaryrefslogtreecommitdiff
path: root/git-am.sh
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2015-06-28 11:18:31 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2015-06-28 14:47:28 -0700
commit84d18c0bcfa17927240cc0322023d91d3797d0f3 (patch)
tree5134b7a02c3ea1219e30cf60bf0db50b0e841180 /git-am.sh
parentindex-pack: terminate object buffers with NUL (diff)
downloadtgif-84d18c0bcfa17927240cc0322023d91d3797d0f3.tar.xz
fsck: it is OK for a tag and a commit to lack the body
When fsck validates a commit or a tag, it scans each line in the header of the object using helper functions such as "start_with()", etc. that work on a NUL terminated buffer, but before a1e920a0 (index-pack: terminate object buffers with NUL, 2014-12-08), the validation functions were fed the object data in a piece of memory that is not necessarily terminated with a NUL. We added a helper function require_end_of_header() to be called at the beginning of these validation functions to insist that the object data contains an empty line before its end. The theory is that the validating functions will notice and stop when it hits an empty line as a normal end of header (or a required header line that is missing) without scanning past the end of potentially not NUL-terminated buffer. But the theory forgot that in the older days, Git itself happily created objects with only the header lines without a body. This caused Git 2.2 and later to issue an unnecessary warning in some existing repositories. With a1e920a0, we do not need to require an empty line (or the body) in these objects to safely parse and validate them. Drop the offending "must have an empty line" check from this helper function, while keeping the other check to make sure that there is no NUL in the header part of the object, and adjust the name of the helper to what it does accordingly. Noticed-by: Wolfgang Denk <wd@denx.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-am.sh')
0 files changed, 0 insertions, 0 deletions