summaryrefslogtreecommitdiff
path: root/t/t9818-git-p4-block.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-03-09 08:29:49 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-03-10 11:51:30 -0800
commita91aca44bf4b3746c3ce03583a1b3418d1610ef7 (patch)
treeeb9db8984d71e3213e169110d3dd09528642eb5d /t/t9818-git-p4-block.sh
parentref-filter: die on parse_commit errors (diff)
downloadtgif-a91aca44bf4b3746c3ce03583a1b3418d1610ef7.tar.xz
ref-filter: use separate cache for contains_tag_algo
The algorithm which powers "tag --contains" uses the TMP_MARK and UNINTERESTING bits, but never cleans up after itself. As a result, stale UNINTERESTING bits may impact later traversals (like "--merged"). We could fix this by clearing the bits after we're done with the --contains traversal. That would be enough to fix the existing problem, but it leaves future developers in a bad spot: they cannot add other traversals that operate simultaneously with --contains (e.g., if you wanted to add "--no-contains" and use both filters at the same time). Instead, we can use a commit slab to store our cached results, which will store the bits outside of the commit structs entirely. This adds an extra level of indirection, but in my tests (running "git tag --contains HEAD" on linux.git), there was no measurable slowdown. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t9818-git-p4-block.sh')
0 files changed, 0 insertions, 0 deletions