All of lore.kernel.org
 help / color / mirror / Atom feed
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?

  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.