On Thu, Aug 16, 2018 at 11:52:13AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think that makes sense. We already see duplicates from
> > for_each_packed_object() when they're in multiple packs, and callers
> > just need to be ready to deal with it (and depending on what you're
> >
Jeff King writes:
> I think that makes sense. We already see duplicates from
> for_each_packed_object() when they're in multiple packs, and callers
> just need to be ready to deal with it (and depending on what you're
> doing, you may actually _want_ the duplicates).
You of course would also
On Wed, Aug 15, 2018 at 10:05:04AM -0400, Derrick Stolee wrote:
> One thing that I realized while reading it is that the multi-pack-index is
> not integrated into the for_each_packed_object method. I was already going
> to work on some cleanups in that area [1][2].
>
> When using the new flag
On 8/10/2018 7:07 PM, Jeff King wrote:
The general idea is that accessing objects in packfile order is way
kinder to the delta base cache, and thus way more efficient. See patches
4 and 7 in particular for discussion and numbers.
I'm primarily interested in cat-file, so this series is focused
> [1/7]: for_each_*_object: store flag definitions in a single location
> [2/7]: for_each_*_object: take flag arguments as enum
> [3/7]: for_each_*_object: give more comprehensive docstrings
> [4/7]: for_each_packed_object: support iterating in pack-order
> [5/7]: t1006: test cat-file
This series is meant to replace the RFC discussion in:
https://public-inbox.org/git/20180808231210.242120-1-jonathanta...@google.com/
and
https://public-inbox.org/git/20180808155045.gb1...@sigill.intra.peff.net/
The general idea is that accessing objects in packfile order is way
kinder to
6 matches
Mail list logo
