All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (Aug 2026, #05)
Date: Thu, 13 Aug 2026 09:59:18 +0200	[thread overview]
Message-ID: <an15Vvcfudlz69TM@pks.im> (raw)
In-Reply-To: <xmqqcxvmvda1.fsf@gitster.g>

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. <anxXbnuRt4I4uPdI@pks.im>
>  source: <20260811121446.2080190-1-christian.couder@gmail.com>

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. <xmqqa4qrxneq.fsf@gitster.g>
>  source: <pull.1922.git.1786516959130.gitgitgadget@gmail.com>

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: <20260805-pks-odb-stream-unification-v2-0-b8c369564641@pks.im>

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. <xmqq5x1fxn5u.fsf@gitster.g>
>  cf. <20260812213438.GC152730@coredump.intra.peff.net>
>  source: <pull.2179.v3.git.1786521801.gitgitgadget@gmail.com>

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
<20260807-b4-pks-odb-generate-pack-v1-0-7dec431ae7cd@pks.im>, 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: <cover.1781294771.git.me@ttaylorr.com>

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

Thanks!

Patrick

      reply	other threads:[~2026-08-13  7:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  4:45 What's cooking in git.git (Aug 2026, #05) Junio C Hamano
2026-08-13  7:59 ` Patrick Steinhardt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=an15Vvcfudlz69TM@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.