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 (May 2026, #01)
Date: Mon, 4 May 2026 16:18:38 +0200	[thread overview]
Message-ID: <afiqvgxwbAOxMsti@pks.im> (raw)
In-Reply-To: <xmqqmryhtar8.fsf@gitster.g>

On Sun, May 03, 2026 at 12:47:23PM +0900, Junio C Hamano wrote:
> * kn/refs-generic-helpers (2026-04-27) 9 commits
>  - refs: use peeled tag values in reference backends
>  - refs: add peeled object ID to the `ref_update` struct
>  - refs: move object parsing to the generic layer
>  - update-ref: handle rejections while adding updates
>  - update-ref: move `print_rejected_refs()` up
>  - refs: return `ref_transaction_error` from `ref_transaction_update()`
>  - refs: extract out reflog config to generic layer
>  - refs: introduce `ref_store_init_options`
>  - refs: remove unused typedef 'ref_transaction_commit_fn'
> 
>  Refactor service routines in the ref subsystem backends.
> 
>  Will merge to 'next'?
>  source: <20260427-refs-move-to-generic-layer-v3-0-e4638dfb7897@gmail.com>

I think [1] is something that may still want to be addressed.

> * js/maintenance-fix-deadlock-on-win10 (2026-04-28) 2 commits
>  - maintenance(geometric): do release the `.idx` files before repacking
>  - mingw: optionally use legacy (non-POSIX) delete semantics
> 
>  To help Windows 10 installations, avoid removing files whose
>  contents are still mmap()'ed.
> 
>  Will merge to 'next'?
>  source: <pull.2103.git.1777380768.gitgitgadget@gmail.com>

I've had a minor nit [2], but other than that this looks good to me.

> * sg/t6112-unwanted-tilde-expansion-fix (2026-04-21) 1 commit
>  - t6112: avoid tilde expansion
> 
>  Test fix.
> 
>  Will merge to 'next'?
>  source: <20260421192132.51172-1-szeder.dev@gmail.com>

This fix looks sensible to me.

> * ps/odb-in-memory (2026-04-10) 18 commits
>  - t/unit-tests: add tests for the in-memory object source
>  - odb: generic in-memory source
>  - odb/source-inmemory: stub out remaining functions
>  - odb/source-inmemory: implement `freshen_object()` callback
>  - odb/source-inmemory: implement `count_objects()` callback
>  - odb/source-inmemory: implement `find_abbrev_len()` callback
>  - odb/source-inmemory: implement `for_each_object()` callback
>  - odb/source-inmemory: convert to use oidtree
>  - oidtree: add ability to store data
>  - cbtree: allow using arbitrary wrapper structures for nodes
>  - odb/source-inmemory: implement `write_object_stream()` callback
>  - odb/source-inmemory: implement `write_object()` callback
>  - odb/source-inmemory: implement `read_object_stream()` callback
>  - odb/source-inmemory: implement `read_object_info()` callback
>  - odb: fix unnecessary call to `find_cached_object()`
>  - odb/source-inmemory: implement `free()` callback
>  - odb: introduce "in-memory" source
>  - Merge branch 'jt/odb-transaction-write' into ps/odb-in-memory
>  (this branch uses jt/odb-transaction-write.)
> 
>  Add a new odb "in-memory" source that is meant to only hold
>  tentative objects (like the virtual blob object that represents the
>  working tree file used by "git blame").
> 
>  Will merge to 'next'?
>  source: <20260410-b4-pks-odb-source-inmemory-v3-0-22fd0fad58fe@pks.im>

This series should be ready, yes.

> * jt/odb-transaction-write (2026-04-02) 7 commits
>  - odb/transaction: make `write_object_stream()` pluggable
>  - object-file: generalize packfile writes to use odb_write_stream
>  - object-file: avoid fd seekback by checking object size upfront
>  - object-file: remove flags from transaction packfile writes
>  - odb: update `struct odb_write_stream` read() callback
>  - odb/transaction: use pluggable `begin_transaction()`
>  - odb: split `struct odb_transaction` into separate header
>  (this branch is used by ps/odb-in-memory.)
> 
>  ODB transaction interface is being reworked to explicitly handle
>  object writes.
> 
>  Will merge to 'next'?
>  source: <20260402213220.2651523-1-jltobler@gmail.com>

The latest version looks good to me.

Thanks!

Patrick

[1]: <87v7dagdjk.fsf@toon--20250203-5JQV3.mail-host-address-is-not-set>
[2]: <afipTWyj2zVYYqMz@pks.im>

  parent reply	other threads:[~2026-05-04 14:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-03  3:47 What's cooking in git.git (May 2026, #01) Junio C Hamano
2026-05-04 13:16 ` Phillip Wood
2026-05-04 14:18 ` Patrick Steinhardt [this message]
2026-05-04 17:44   ` Karthik Nayak

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=afiqvgxwbAOxMsti@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.