Jeff King <peff@xxxxxxxx> writes: > The "--use-bitmap-index" option is usually aspirational: if we have > bitmaps and the request can be fulfilled more quickly using them we'll > do so, but otherwise fall back to a non-bitmap traversal. > > The exception is object filtering, which explicitly dies if the two > options are combined. Let's convert this to the usual fallback behavior. > > This is a minor convenience for now (since the caller can easily know > that --filter and --use-bitmap-index don't combine), but will become > much more useful as we start to support _some_ filters with bitmaps, but > not others. Makes sense. Perhaps the option should have been called allow-bitmap-index or something along that line, but it is too late ;-) > +test_expect_success 'set up bitmapped repo' ' > + # one commit will have bitmaps, the other will not > + test_commit one && > + git repack -adb && > + test_commit two > +' > + > +test_expect_success 'filters fallback to non-bitmap traversal' ' > + # use a path-based filter, since they are inherently incompatible with > + # bitmaps (i.e., this test will never get confused by later code to > + # combine the features) > + filter=$(echo "!one" | git hash-object -w --stdin) && > + git rev-list --objects --filter=sparse:oid=$filter HEAD >expect && > + git rev-list --use-bitmap-index \ > + --objects --filter=sparse:oid=$filter HEAD >actual && > + test_cmp expect actual > +' OK.
