From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What's cooking in git.git (May 2025, #08; Tue, 27)
Date: Tue, 27 May 2025 22:37:36 -0400 [thread overview]
Message-ID: <aDZ28C8bqnstJ68r@nand.local> (raw)
In-Reply-To: <xmqqfrgptv10.fsf@gitster.g>
On Tue, May 27, 2025 at 05:54:03PM -0700, Junio C Hamano wrote:
> * tb/prepare-midx-pack-cleanup (2025-05-27) 6 commits
> - midx: return a `packed_git` pointer from `prepare_midx_pack()`
> - midx-write.c: extract inner loop from fill_packs_from_midx()
> - midx-write.c: simplify fill_packs_from_midx()
> - midx-write.c: guard against incremental MIDXs in want_included_pack()
> - pack-bitmap.c: fix broken warning() when missing MIDX'd pack
> - Merge branch 'ps/midx-negative-packfile-cache' into tb/prepare-midx-pack-cleanup
> (this branch uses ps/midx-negative-packfile-cache.)
>
> Improvement on Multi-pack-index API.
>
> Comments?
> source: <cover.1748198489.git.me@ttaylorr.com>
I'm planning on sending out a new round of this tomorrow morning (CDT)
based on some of Patrick's feedback. That should hopefully be in good
enough shape to start merging down.
> * ps/midx-negative-packfile-cache (2025-05-20) 2 commits
> - midx: stop repeatedly looking up nonexistent packfiles
> - packfile: explain ordering of how we look up auxiliary pack files
> (this branch is used by tb/prepare-midx-pack-cleanup.)
>
> When a stale .midx file refers to .pack files that no longer exist,
> we ended up checking for these non-existent files repeatedly, which
> has been optimized by memoizing the non-existence.
>
> Will merge to 'next'?
> source: <20250520-pks-pack-avoid-stats-on-missing-v2-0-333c5217fb05@pks.im>
Yeah, this one looks good to me.
> * tb/midx-avoid-cruft-packs (2025-04-15) 9 commits
> - repack: exclude cruft pack(s) from the MIDX where possible
> - pack-objects: introduce '--stdin-packs=follow'
> - pack-objects: swap 'show_{object,commit}_pack_hint'
> - pack-objects: fix typo in 'show_object_pack_hint()'
> - pack-objects: perform name-hash traversal for unpacked objects
> - pack-objects: declare 'rev_info' for '--stdin-packs' earlier
> - pack-objects: factor out handling '--stdin-packs'
> - pack-objects: limit scope in 'add_object_entry_from_pack()'
> - pack-objects: use standard option incompatibility functions
>
> "pack-objects" has been taught to avoid pointing into objects in
> cruft packs from midx.
>
> Expecting a (hopefully small and final) reroll?
> cf.<CABPp-BEukTWwsuC7MMR8D5_UAhyw-LgT=DsPKAWeR_ZmVVhjzQ@mail.gmail.com>
> source: <cover.1744757204.git.me@ttaylorr.com>
I have a couple of minor tweaks that have been sitting in my queue for
too long. I'll plan on sending those out tomorrow morning as well.
> * tb/pack-bitmap-lookup-tables (2025-04-17) 4 commits
> - t/perf/lib-bitmap.sh: avoid test_perf during setup
> - t/perf: avoid testing bitmaps without lookup table
> - p5312: removed duplicate performance test script
> - pack-bitmap: write lookup table extension by default
>
> Enable lookup tables extension in pack bitmap (and midx bitmap) by
> default.
>
> Comments?
> source: <cover.1744924321.git.me@ttaylorr.com>
Let's drop this one for now. There's enough left for this one that I
would rather focus on polishing the release now that we are on the eve
of -rc0.
> * ds/path-walk-2 (2025-05-16) 13 commits
> - pack-objects: allow --shallow and --path-walk
> - path-walk: add new 'edge_aggressive' option
> - pack-objects: thread the path-based compression
> - pack-objects: refactor path-walk delta phase
> - scalar: enable path-walk during push via config
> - pack-objects: enable --path-walk via config
> - repack: add --path-walk option
> - t5538: add tests to confirm deltas in shallow pushes
> - pack-objects: introduce GIT_TEST_PACK_PATH_WALK
> - p5313: add performance tests for --path-walk
> - pack-objects: update usage to match docs
> - pack-objects: add --path-walk option
> - pack-objects: extract should_attempt_deltas()
>
> "git pack-objects" learns to find delta bases from blobs at the
> same path, using the --path-walk API.
>
> Comments?
> source: <pull.1819.v3.git.1747419124.gitgitgadget@gmail.com>
I expect that this one should be ready to go, but I'd like to give it a
read through with fresh(er) eyes tomorrow before declaring victory here.
Thanks,
Taylor
next prev parent reply other threads:[~2025-05-28 2:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 0:54 What's cooking in git.git (May 2025, #08; Tue, 27) Junio C Hamano
2025-05-28 2:37 ` Taylor Blau [this message]
2025-05-28 21:01 ` Jean-Noël AVILA
2025-05-28 22:02 ` Junio C Hamano
2025-05-29 20:33 ` Jean-Noël AVILA
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=aDZ28C8bqnstJ68r@nand.local \
--to=me@ttaylorr.com \
--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.