Re: What's cooking in git.git (Apr 2024, #05; Fri, 12)

From: Patrick Steinhardt <ps@pks.im>
Date: Apr 15, 2024, 07:23 UTC
Message-ID: <ZhzV38Ga1Lg99bUF@tanuki>
In-Reply-To: <xmqqfrvqhwlg.fsf@gitster.g>

On Fri, Apr 12, 2024 at 06:36:59PM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> * ta/fast-import-parse-path-fix (2024-04-12) 8 commits
>  - fast-import: make comments more precise
>  - fast-import: forbid escaped NUL in paths
>  - fast-import: document C-style escapes for paths
>  - fast-import: improve documentation for path quoting
>  - fast-import: remove dead strbuf
>  - fast-import: allow unquoted empty path for root
>  - fast-import: directly use strbufs for paths
>  - fast-import: tighten path unquoting
> 
>  The way "git fast-import" handles paths described in its input has
>  been tightened up and more clearly documented.
> 
>  Will merge to 'next'?
>  source: <cover.1712907684.git.thalia@archibald.dev>

Yeah, I think the series is good to be merged now.

Show 16 quoted lines

> * ps/reftable-block-iteration-optim (2024-03-27) 9 commits
>  - reftable/block: reuse `zstream` state on inflation
>  - reftable/block: open-code call to `uncompress2()`
>  - reftable/block: reuse uncompressed blocks
>  - reftable/reader: iterate to next block in place
>  - reftable/block: move ownership of block reader into `struct table_iter`
>  - reftable/block: introduce `block_reader_release()`
>  - reftable/block: better grouping of functions
>  - reftable/block: merge `block_iter_seek()` and `block_reader_seek()`
>  - reftable/block: rename `block_reader_start()`
> 
>  The code to iterate over reftable blocks has seen some optimization
>  to reduce memory allocation and deallocation.
> 
>  Needs review.
>  source: <cover.1711519925.git.ps@pks.im>

This series received two favorable reviews [1][2]. Justin pointed out one typo in a commit message that can be fixed like this:

 1:  eb487557a8 =  1:  eb487557a8 reftable/block: rename `block_reader_start()`
 2:  d0b318b8ee =  2:  d0b318b8ee reftable/block: merge `block_iter_seek()` and `block_reader_seek()`
 3:  c3f928d1e9 =  3:  c3f928d1e9 reftable/block: better grouping of functions
 4:  35f1bf5072 =  4:  35f1bf5072 reftable/block: introduce `block_reader_release()`
 5:  e8e8bbae62 =  5:  e8e8bbae62 reftable/block: move ownership of block reader into `struct table_iter`
 6:  685f0a40bc =  6:  685f0a40bc reftable/reader: iterate to next block in place
 7:  a7906a3383 =  7:  a7906a3383 reftable/block: reuse uncompressed blocks
 8:  6635c7b986 =  8:  6635c7b986 reftable/block: open-code call to `uncompress2()`
 9:  587b5601c0 =  9:  587b5601c0 reftable/block: reuse `zstream` state on inflation
10:  cc5ff0d598 ! 10:  935860c567 reftable/block: avoid copying block iterators on seek
    @@ Commit message
         When seeking a reftable record in a block we need to position the
         iterator _before_ the sought-after record so that the next call to
         `block_iter_next()` would yield that record. To achieve this, the loop
    -    that performs the linear needs to restore the previous position once it
    +    that performs the linear seeks to restore the previous position once it
         has found the record.
     
         This is done by advancing two `block_iter`s: one to check whether the

I don't really feel like it is worth it to reroll the whole series just to fix this one typo, but can do so if preferred by you. Just let me know.

Thanks!

Patrick

[1]: <vab3mzg3meohikmfl5v57uxj6w7w2odrx7cvhmoto7am2bl2yt@6l4salel4ko5> [2]: <CAOLa=ZRxQPnPxM+sZtuL-a5DVJL8Xx+D7t2d4cLoPT-hLaK_UA@mail.gmail.com>