From: Patrick Steinhardt <ps@pks.im>
Date: Tue, 12 Mar 2024 04:46:16 GMT
Subject: Re: What's cooking in git.git (Mar 2024, #03; Mon, 11)
Message-ID: <Ze_eGIYeDY1YpptQ@tanuki>
In-Reply-To: <xmqqy1aol1lv.fsf@gitster.g>

On Mon, Mar 11, 2024 at 05:45:16PM -0700, Junio C Hamano wrote:
> * ps/reftable-block-search-fix (2024-03-07) 2 commits
>  - reftable/block: fix binary search over restart counter
>  - reftable/record: fix memory leak when decoding object records
> 
>  The reftable code has its own custom binary search function whose
>  comparison callback has an unusual interface, which caused the
>  binary search to degenerate into a linear search, which has been
>  corrected.
> 
>  Will merge to 'next'?
>  source: <cover.1709843663.git.ps@pks.im>

The binary search logic still isn't perfect, but the series already
fixes some issues. I'll send the follow-up fixes in a separate
patch series next week.

So yes, I think this can be merged.

> * ps/reftable-reflog-iteration-perf (2024-03-05) 8 commits
>  - refs/reftable: track last log record name via strbuf
>  - reftable/record: use scratch buffer when decoding records
>  - reftable/record: reuse message when decoding log records
>  - reftable/record: reuse refnames when decoding log records
>  - reftable/record: avoid copying author info
>  - reftable/record: convert old and new object IDs to arrays
>  - refs/reftable: reload correct stack when creating reflog iter
>  - Merge branch 'ps/reftable-iteration-perf-part2' into ps/reftable-reflog-iteration-perf
>  (this branch uses ps/reftable-iteration-perf-part2.)
> 
>  The code to iterate over reflogs in the reftable has been optimized
>  to reduce memory allocation and deallocation.
> 
>  Reviewed-by: Josh Steadmon <steadmon@google.com>
>  cf. <Ze9eX-aaWoVaqsPP@google.com>
> 
>  Will merge to 'next'?
>  source: <cover.1709640322.git.ps@pks.im>

Fine with me, too. Josh was asking for a test for the first patch, but
I don't really have an idea for how to write one.

> * ps/reftable-stack-tempfile (2024-03-07) 4 commits
>  - reftable/stack: register compacted tables as tempfiles
>  - reftable/stack: register lockfiles during compaction
>  - reftable/stack: register new tables as tempfiles
>  - lockfile: report when rollback fails
> 
>  The code in reftable backend that creates new table files works
>  better with the tempfile framework to avoid leaving cruft after a
>  failure.
> 
>  Will merge to 'next'?
>  source: <cover.1709816483.git.ps@pks.im>

This one should be good to go, as well.

Thanks!

Patrick