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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).