On 8/21/2018 3:07 PM, Jeff King wrote:
When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so code which has performed a
walk can query it.
This makes a lot of sense. Based on the amount of time the "Counting
Objects" blog post [1] spent talking about delta bases, I would have
assumed this "haves" bitmap was already part of it. But, I can also see
how it could be dropped if you are focusing on performance for 'git clone'.
A few notes on the accessor interface:
- the bitmap code calls these "haves" because it grew out
of the want/have negotiation for fetches. But really,
these are simply the objects that would be flagged
UNINTERESTING in a regular traversal. Let's use that
more universal nomenclature for the external module
interface. We may want to change the internal naming
inside the bitmap code, but that's outside the scope of
this patch.
I saw the uninteresting-vs-haves name confusion in the patch below, but
I agree with your logic here.
Sorry that I'm late to the party, but I was interested in the topic.
Thanks,
-Stolee
[1] https://githubengineering.com/counting-objects/
"Counting Objects" by Vincent Martí
