Clones with fetch.bundleURI slower than standard, full clone?

["Knop, Ryszard" <ryszard.knop@intel.com>]

Hey all,

I'm working on a Linux kernel-related CI system where we need to
perform full clones of the kernel repo in most jobs. Because of some
jobs in the pipeline, it usually cannot be a shallow clone :( Since the
kernel repo is large and slow to clone, and I don't want to put undue
stress on the remote host, I used git bundles, where CI clones the repo
over a weekend, packages that as a bundle, then in jobs it gets used
like this (weird, but works for <REF> being a branch, tag or a specific
commit hash):

git init
git remote add origin <REPO-URL>
git config set fetch.bundleURI <BUNDLE-URL>
git fetch origin <REF>
git reset --hard FETCH_HEAD

Cloning a repo this way takes 4-5mins. Unpacking a bundle appears to be
super slow. Not even faster than just running a full, normal clone from
the remote server, actually (~3-4mins for a single branch).

On one of the build VMs, with Git 2.53 (stock Ubuntu 26.04), GIT_TRACE
suggests most of the time is spent in some variation of `/usr/lib/git-
core/git index-pack --stdin -v --fix-thin '--keep=fetch-pack 39430 on
build-server' --check-self-contained-and-connected`, and indeed that
process burns 100% of its single thread for most of that time.

Is it expected that doing it this way is so slow? The alternative is to
just package and work with the whole bare repo, but bundles appear to
be an elegant way of dealing with exactly this scenario.

Thanks, Ryszard