You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CIHelper: offer to pre-populate the upstream branches
GitGitGadget's code has auto-magic logic to fetch those, but even in a
partial clone that would result in a ~100MB fetch. Maybe that's okay,
and I worry too much about bandwidth? Inside hosted Actions runners,
download speeds of ~30MB/sec are not unheard of, after all... But then,
I do think that too few people are careful to waste less resources than
is ethical, so I want to be mindful.
Note that we use a "funny" `--filter=blob:limit=1g` option here instead
of the more natural `--no-filter`: Git introduced a subtle bug (that I
have no time nor patience to pursue any further) in v2.48.0-rc0~58^2
(index-pack: repack local links into promisor packs, 2024-11-01) that
would occasionally result in this strange error when fetching in the
partial clone after an occasional `--no-filter` fetch:
git -C git.git fetch upstream
remote: Enumerating objects: 2, done.
remote: Counting objects: 100% (2/2), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (2/2), 14.66 KiB | 7.33 MiB/s, done.
BUG: builtin/pack-objects.c:4320: should_include_obj should only be called on existing objects
error: pack-objects died of signal 6
fatal: could not finish pack-objects to repack local links
fatal: index-pack failed
The most likely reason is that the logic needs to improved to
accommodate for situations where commits are fetched into a non-promisor
pack as part of fetch that notices that some of the commits reachable
from that pack are present locally (but they are in promisor packs,
which the naïve `pack-objects` call fails to anticipate). But again, I
do not have time to pursue this any further. Keeping out non-promisor
packs avoids the bug, and that's that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
0 commit comments