summaryrefslogtreecommitdiff
path: root/mergetools/diffmerge
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2019-10-18 00:42:13 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2019-10-21 11:15:23 +0900
commitc78fe00459d49cd57cbfabc5c564af0cb9a934f1 (patch)
tree0e6dab31b2ce80a184e8d121424e7081a82ae0f6 /mergetools/diffmerge
parentGit 2.24-rc0 (diff)
downloadtgif-c78fe00459d49cd57cbfabc5c564af0cb9a934f1.tar.xz
parse_commit_buffer(): treat lookup_commit() failure as parse error
While parsing the parents of a commit, if we are able to parse an actual oid but lookup_commit() fails on it (because we previously saw it in this process as a different object type), we silently omit the parent and do not report any error to the caller. The caller has no way of knowing this happened, because even an empty parent list is a valid parse result. As a result, it's possible to fool our "rev-list" connectivity check into accepting a corrupted set of objects. There's a test for this case already in t6102, but unfortunately it has a slight error. It creates a broken commit with a parent line pointing to a blob, and then checks that rev-list notices the problem in two cases: 1. the "lone" case: we traverse the broken commit by itself (here we try to actually load the blob from disk and find out that it's not a commit) 2. the "seen" case: we parse the blob earlier in the process, and then when calling lookup_commit() we realize immediately that it's not a commit The "seen" variant for this test mistakenly parsed another commit instead of the blob, meaning that we were actually just testing the "lone" case again. Changing that reveals the breakage (and shows that this fixes it). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'mergetools/diffmerge')
0 files changed, 0 insertions, 0 deletions