]> git.ipfire.org Git - thirdparty/git.git/commit - builtin/rev-list.c
rev-list: disable bitmaps when "-n" is used with listing objects
authorJeff King <peff@peff.net>
Fri, 3 Jun 2016 07:08:05 +0000 (03:08 -0400)
committerJunio C Hamano <gitster@pobox.com>
Fri, 3 Jun 2016 16:01:02 +0000 (09:01 -0700)
commitfb85db84dcc36dcc3cdd5fc744280334bbe8eb47
treed0e57dc4c5a48798a9d6109da480948708fb4205
parent5c9f9bf313e872934c9b4563b7b0bcdedb39eb86
rev-list: disable bitmaps when "-n" is used with listing objects

You can ask rev-list to use bitmaps to speed up an --objects
traversal, which should generally give you your answers much
faster.

Likewise, you can ask rev-list to limit such a traversal
with `-n`, in which case we'll show only a limited set of
commits (and only the tree and commit objects directly
reachable from those commits).

But if you do both together, the results are nonsensical. We
end up limiting any fallback traversal we do to _find_ the
bitmaps, but the actual set of objects we output will be
picked arbitrarily from the union of any bitmaps we do find,
and will involve the objects of many more commits.

It's possible that somebody might want this as a "show me
what you can, but limit the amount of work you do" flag.
But as with the prior commit clamping "--count", the results
are basically non-deterministic; you'll get the values from
some commits between `n` and the total number, and you can't
tell which.

And unlike the `--count` case, we can't easily generate the
"real" value from the bitmap values (you can't just walk
back `-n` commits and subtract out the reachable objects
from the boundary commits; the bitmaps for `X` record its
total reachability, so you don't know which objects are
directly from `X` itself, which from `X^`, and so on).

So let's just fallback to the non-bitmap code path in this
case, so we always give a sane answer.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/rev-list.c