On Tue, Aug 21, 2018 at 03:47:36PM -0400, Derrick Stolee wrote: > 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'. I think that blog post was written after we were already using this patch. ;) > > 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. This has already missed the freeze for v2.19, so I think there is plenty of time. More review would be welcome. -Peff
