Re: What's cooking in git.git (Aug 2026, #05)

Patrick Steinhardt <[email protected]>
Newsgroups org.kernel.vger.git
Message-ID <[email protected]>
On Wed, Aug 12, 2026 at 09:45:58PM -0700, Junio C Hamano wrote:
> * cc/git-shallow-file-wo-value (2026-08-11) 1 commit
>  - git: avoid segfault on "git --shallow-file" without a value
> 
>  The '--shallow-file' option of 'git' command requires a value, but the
>  code did not check the presence of a value and instead segfaulted
>  without one, which has been corrected.
> 
>  Will merge to 'next'?
>  cf. <[email protected]>
>  source: <[email protected]>

This version looks good to me.

> * en/sequencer-lose-pretty-given (2026-08-11) 1 commit
>  - sequencer: remove unnecessary variable setting
> 
>  The setting of a now-unused member revs.pretty_given in the
>  sequencer machinery has been removed.
> 
>  Will merge to 'next'?
>  cf. <[email protected]>
>  source: <[email protected]>

Yeah, this patch looks sensible to me.

> * ps/odb-streams (2026-08-05) 8 commits
>  - odb/streaming: unify function names to create new streams
>  - odb/streaming: rename `struct input_zstream_data`
>  - odb/streaming: rename `struct read_object_fd_data`
>  - odb/streaming: consolidate read and write streams
>  - odb/streaming: rename `struct odb_read_stream`
>  - odb/streaming: support streaming arbitrary object types
>  - odb/streaming: drop `is_finished` field
>  - odb/streaming: track write stream size in the structure
> 
>  The 'struct odb_read_stream' and 'struct odb_write_stream'
>  structures have been consolidated into a single unified 'struct
>  odb_stream' structure, simplifying object database streaming APIs
>  and enabling streaming of arbitrary object types.
> 
>  Will merge to 'next'?
>  cf. <anuBdm29ye_qV_Rq@denethor>
>  source: <[email protected]>

Yup, I think this series should be ready.

> * js/coverity-unchecked-returns-fix (2026-08-12) 12 commits
>  - bisect: handle dup() failure when redirecting stdout
>  - bisect: check get_terms return at all call sites
>  - bisect: check strbuf_getline_lf return when reading terms
>  - transport-helper: warn when export-marks file cannot be finalized
>  - transport-helper: check dup() return in get_exporter
>  - compat/pread: check initial lseek for errors
>  - last-modified: handle repo_parse_commit() failures
>  - reftable tests: check reftable_table_init_ref_iterator() return
>  - reftable/block: check deflateInit() return value
>  - reftable: handle block-writer initialization errors
>  - config: propagate launch_editor() failure in show_editor()
>  - http: die on curl_easy_duphandle failure in get_active_slot
> 
>  A handful of code paths have been corrected to check return values
>  from functions like curl_easy_duphandle(), deflateInit(), lseek(),
>  dup(), and strbuf_getline_lf(), resolving several Coverity warnings
>  about unchecked returns.
> 
>  Will merge to 'next'?
>  cf. <[email protected]>
>  cf. <[email protected]>
>  source: <[email protected]>

I think this series should be ready.

> * tb/send-pack-no-ref-delta (2026-07-12) 4 commits
>  - send-pack: honor `no-ref-delta` capability
>  - pack-objects: support reuse with `--no-ref-delta`
>  - pack-objects: introduce `--no-ref-delta`
>  - t/helper: teach pack-deltas to list delta entries
> 
>  'git send-pack' has been taught to refrain from sending 'REF_DELTA'
>  encoded packfiles when the other side asks it to.
> 
>  Needs review.
>  source: <alQ7WKITYDXfiVn9@com-79390>

In <an0EkMZGEbg6LERc@com-79390> we've agreed that this series can be
evicted for now in favor of
<[email protected]>, as Taylor
still needs some more time to rethink the approach in there.

> * tb/midx-incremental-custom-base (2026-06-12) 3 commits
>  - midx-write: include packs above custom incremental base
>  - midx: pass custom '--base' through incremental writes
>  - t5334: expose shared `nth_line()` helper
> 
>  The 'git multi-pack-index write --incremental' command has been
>  corrected to properly honor the '--base' option.  Previously, the
>  custom base was ignored by the normal write path; packs from layers
>  above the selected base were incorrectly skipped by the pack exclusion
>  logic, and reachability closure for bitmaps was broken.
> 
>  Needs review.
>  source: <[email protected]>

I'll try to have a look at this series later today.

Thanks!

Patrick
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.