From: Taylor Blau <me@ttaylorr.com>
To: git@vger.kernel.org
Subject: [NOTES 06/11] Repository maintenance long-term goals
Date: Mon, 6 Oct 2025 15:19:39 -0400 [thread overview]
Message-ID: <aOQWS+ZJdXr73PE0@nand.local> (raw)
In-Reply-To: <aOQVeVYY6zadPjln@nand.local>
Topic: Repository maintenance long-term goals
Leader: Taylor Blau
* Taylor's talk was limited towards the end. Could expand on that future work.
* Constant repacking into a single pack was historically the major problem.
* Doing that less (because of geometric repacking) helps, but it's still a
potential issue when it does occur. Gets them 98% of the way.
* Future items were geometric reachability, ?, best effort gc
* Previously during geometric, used to accumulate loose objects too. 6 months
ago they changed to an approach where the big cruft pack could be excluded
from the midx.
* Challenge would be to do a full complete repack without rewriting all of the
midx chain.
* Because bitmap is tied to object order in a pack, need something like
tombstones to not break the bitmaps. Need the tombstone to know that we don't
have the data.
* Unitary midx idea - Taylor designed the chained midx before he figured out the
repacking strategy. MIDX and pack index duplicate the data. No reason to
de-dup other than for space saving. Could even skip having idx, but plenty of
old git versions can't read midx.
* brian - there may be other implementations, such as git lfs, that don't use
midx and object id mappings in pack idx v3 aren't supported in midx either.
* Nothing preventing you from having two parallel repacks, one that's geometric
and one that's trying to do an all-into-one.
next prev parent reply other threads:[~2025-10-06 19:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 19:16 Notes from the Git Contributor's Summit, 2025 Taylor Blau
2025-10-06 19:18 ` [NOTES 01/11] SHA-256 and interoperability work Taylor Blau
2025-10-06 19:18 ` [NOTES 02/11] First-class conflicts in Git? Taylor Blau
2025-10-06 19:18 ` [NOTES 03/11] The future of history rewriting - rebase, replay and history (+Change-IDs) Taylor Blau
2025-10-06 19:18 ` [NOTES 04/11] Rust Taylor Blau
2025-10-06 19:19 ` [NOTES 05/11] Pluggable object databases Taylor Blau
2025-10-06 19:19 ` Taylor Blau [this message]
2025-10-06 19:19 ` [NOTES 07/11] Change-ID Header in Git Taylor Blau
2025-10-06 19:20 ` [NOTES 08/11] Resumable fetch / push Taylor Blau
2025-10-06 19:20 ` [NOTES 09/11] Git 3.0 Taylor Blau
2025-10-06 19:20 ` [NOTES 10/11] How can companies respectfully engage contractors to work on Git? Taylor Blau
2025-10-06 19:20 ` [NOTES 11/11] Conservancy 2025 updates 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=aOQWS+ZJdXr73PE0@nand.local \
--to=me@ttaylorr.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.