From: Taylor Blau <ttaylorr@openai.com>
To: git@vger.kernel.org
Subject: [NOTES 05/07] What can we do next with pluggable ODB?
Date: Tue, 6 Oct 2026 11:06:31 -0700 [thread overview]
Message-ID: <summit-2026.94e33e9ddf234334.05@ttaylorr.com> (raw)
In-Reply-To: <summit-2026.94e33e9ddf234334.00@ttaylorr.com>
Topic: What can we do next with pluggable ODB?
* Emily: We saw this working in Patrick's talk. What do we want to do
with it next?
* Patrick: Most things work, but we are not all the way there yet;
commit-graph and MIDX are examples. The plan is to add a repository
extension in 2.57.
* Peff: From the Mercurial talk, you can convince Git to make good
deltas, but doing so has a cost. I do not think the ODB API is at a
level where deltas can be created on the fly.
* Patrick: I think we can do that. They have information we do not have.
Renames are tricky.
* Peff: The ODB does not know anything beyond the content. Could we give
it more information?
* Patrick: We may want to evolve this based on the representation. We
could pass a `struct commit *` into the ODB API instead of just
content.
* Peff: What we have now is a reasonable stopgap.
* Patrick: Content-defined chunking is another possibility.
* Taylor: Would that be at the object layer, or a property of a
particular ODB store implementation?
* Patrick: I would like to do it natively, but that seems like a large
change.
* brian: It could be part of a new pack/index format. I am very much in
favor of content-defined chunking.
* Peff: There is a logical object model. Would this be a new object
type, where a chunked object and a blob have different hashes, or
something below that?
* Patrick: We could start at the storage layer and eventually move it to
the object layer.
* Taylor: Perhaps, but perhaps not. This may be easier than we are
thinking.
* Patrick: Moving the ecosystem may be difficult.
* brian: We could have a compatibility fallback.
* Peff: Then we would have two equivalent representations of an object
which do not hash to the same thing.
* brian: We could introduce a pack-only object type.
* Peff: Which OID would I refer to?
* brian: The blob's OID.
* Taylor: That is analogous to REF_DELTA and OFS_DELTA: multiple
representations of the same thing.
* brian: We would need a format extension, because we are out of bits.
* Patrick: Would we still want to put it in a pack?
* brian: Yes.
* Patrick: Start with the storage layer, then see where it goes.
* Patrick: Would this only be for blobs?
* Taylor: Is "chunked" a refinement of a blob, or an attribute
independent of object type?
* brian: Trees are not currently binary-searchable. It would be nice to
fix that too.
* Patrick: Perhaps reftable could provide inspiration there.
* Emily: After Patrick's talk, my skip-level manager asked whether we
could build a commit cloud with Git. What else could we do that is
totally wild?
next prev parent reply other threads:[~2026-10-06 18:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 18:05 Notes from the Git Contributor's Summit, 2026 Taylor Blau
2026-10-06 18:06 ` [NOTES 01/07] Security mailing list and security process Taylor Blau
2026-10-06 18:06 ` [NOTES 02/07] Git 3.0 Taylor Blau
2026-10-06 18:06 ` [NOTES 03/07] Documentation Taylor Blau
2026-10-07 4:49 ` Todd Zullinger
2026-10-07 17:38 ` Junio C Hamano
2026-10-06 18:06 ` [NOTES 04/07] Outreachy sponsorship Taylor Blau
2026-10-06 18:06 ` Taylor Blau [this message]
2026-10-06 18:06 ` [NOTES 06/07] AI contribution policy Taylor Blau
2026-10-06 18:06 ` [NOTES 07/07] Protocol v2 for pushes Taylor Blau
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=summit-2026.94e33e9ddf234334.05@ttaylorr.com \
--to=ttaylorr@openai.com \
--cc=git@vger.kernel.org \
/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.