> * jm/cache-entry-from-mem-pool (2018-05-24) 7 commits
>  - block alloc: add validations around cache_entry lifecyle
>  - block alloc: allocate cache entries from mem_pool
>  - mem-pool: fill out functionality
>  - mem-pool: add lifecycle management functions
>  - mem-pool: only search head block for available space
>  - block alloc: add lifecycle APIs for cache_entry structs
>  - read-cache: teach refresh_cache_entry() to take istate
>
>  For a large tree, the index needs to hold many cache entries
>  allocated on heap.  These cache entries are now allocated out of a
>  dedicated memory pool to amortize malloc(3) overhead.
>
>  Is this ready for 'next'?

https://public-inbox.org/git/CAGZ79kZ-1jwnhzZrCeoZTZrNSwmnO=6asWQgWXRj7tjfYVr=-a...@mail.gmail.com/

I wanted to give it one final read, as Jameson mentioned to
he might resend addressing questions from the last round.
I think it is not quite there yet.


> * sb/object-store-grafts (2018-05-18) 19 commits
[...]
>  (this branch uses sb/object-store-alloc.)
>
>  The conversion to pass "the_repository" and then "a_repository"
>  throughout the object access API continues.
>
>  Will merge to and cook in 'next'.

> * sb/object-store-alloc (2018-05-16) 13 commits
[...]
>  - repository: introduce parsed objects field
>  (this branch is used by sb/object-store-grafts.)
>
>  The conversion to pass "the_repository" and then "a_repository"
>  throughout the object access API continues.
>
>  Will merge to and cook in 'next'.

Thanks.
Should I continue to build on top of these series or merge in side branches
to have a newer base? c.f.
https://public-inbox.org/git/20180530004810.30076-1-sbel...@google.com/


> * sb/diff-color-move-more (2018-05-21) 8 commits
[...]
>  "git diff --color-moved" feature has further been tweaked.
>
>  Will kick back to 'pu'.
>  cf. <cagz79kag9m02xtjkg05ape4grq2wbwsmur3jdwfyhsmawr7...@mail.gmail.com>

I hope to get this out again, today.

Reply via email to