ref-filter: use separate cache for contains_tag_algo
commita91aca44bf4b3746c3ce03583a1b3418d1610ef7
authorJeff King <peff@peff.net>
Thu, 9 Mar 2017 13:29:49 +0000 (9 08:29 -0500)
committerJunio C Hamano <gitster@pobox.com>
Fri, 10 Mar 2017 19:51:30 +0000 (10 11:51 -0800)
treeeb9db8984d71e3213e169110d3dd09528642eb5d
parentd344d1cb8a1d1bea268ec78f5d7315381a0a6c96
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>
ref-filter.c