diff options
author | Jeff King <peff@peff.net> | 2017-03-09 08:29:49 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-03-10 11:51:30 -0800 |
commit | a91aca44bf4b3746c3ce03583a1b3418d1610ef7 (patch) | |
tree | eb9db8984d71e3213e169110d3dd09528642eb5d /builtin/ls-files.c | |
parent | ref-filter: die on parse_commit errors (diff) | |
download | tgif-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 'builtin/ls-files.c')
0 files changed, 0 insertions, 0 deletions