summaryrefslogtreecommitdiff
path: root/builtin
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2012-10-04 07:58:15 (GMT)
committerJunio C Hamano <gitster@pobox.com>2012-10-05 03:34:28 (GMT)
commit44da6f69ecc4200a488b0647be9f5cb75cae6c4d (patch)
treed6cacf295b494e83a0e16d0f2e8b6d37a94d4ae7 /builtin
parent9376c8603fc1f9b5bf663b76705dfee77f71ef82 (diff)
downloadgit-44da6f69ecc4200a488b0647be9f5cb75cae6c4d.zip
git-44da6f69ecc4200a488b0647be9f5cb75cae6c4d.tar.gz
git-44da6f69ecc4200a488b0647be9f5cb75cae6c4d.tar.bz2
peel_ref: use faster deref_tag_noverify
When we are asked to peel a ref to a sha1, we internally call deref_tag, which will recursively parse each tagged object until we reach a non-tag. This has the benefit that we will verify our ability to load and parse the pointed-to object. However, there is a performance downside: we may not need to load that object at all (e.g., if we are listing peeled simply listing peeled refs), or it may be a large object that should follow a streaming code path (e.g., an annotated tag of a large blob). It makes more sense for peel_ref to choose the fast thing rather than performing the extra check, for two reasons: 1. We will already sometimes short-circuit the tag parsing in favor of a peeled entry from a packed-refs file. So we are already favoring speed in some cases, and it is not wise for a caller to rely on peel_ref to detect corruption. 2. We already silently ignore much larger corruptions, like a ref that points to a non-existent object, or a tag object that exists but is corrupted. 2. peel_ref is not the right place to check for such a database corruption. It is returning only the sha1 anyway, not the actual object. Any callers which use that sha1 to load an object will soon discover the corruption anyway, so we are really just pushing back the discovery to later in the program. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin')
0 files changed, 0 insertions, 0 deletions