Derrick Stolee <stolee@xxxxxxxxx> writes: > On 4/5/2021 9:08 PM, Junio C Hamano wrote:> * ds/clarify-hashwrite (2021-03-26) 1 commit >> (merged to 'next' on 2021-03-30 at 701f5c0696) >> + csum-file: make hashwrite() more readable >> >> The hashwrite() API always resulted in a call to write(2), even >> when writing a small amount of bytes that would still fit in the >> internal buffer held by the hashfile struct. It has been updated >> to delay the writing until the buffer is filled or the hashfile >> concluded for performance. > > Sorry for not noticing earlier, but this branch description is > based on my erroneous understanding of the change in v1. The > commit now only rearranges and comments the method to be more > clear that it is correctly buffering the data. Perhaps this > could be a substitute? > > The hashwrite() API uses a buffering mechanism to avoid calling > write(2) too frequently. This logic has been refactored to be > easier to understand. Thanks, yes I did recall we replaced this topic with an updated version that concentrates on readability. The proposed text looks good. >> * ds/sparse-index (2021-03-30) 21 commits >> ... >> (this branch is used by ds/sparse-index-protections.) >> >> Both in-core and on-disk index has been updated to optionally omit >> individual entries and replace them with the tree object that >> corresponds to the directory that contains them when the "cone" >> mode of sparse checkout is in use. > > I believe this one has been stable for a little while. Do you > think it could be a candidate for 'next' soon? Alternatively, > you could wait and merge ds/sparse-index and > ds/sparse-index-protections at the same time. I just know that > the second series is causing some merge contention with other > topics. I was planning to give this another scan before marking it as "Merge to 'next'", hopefully before the end of this week. Thanks.
