Git background task storage incident

Background git fetch tmp_pack Disk Full

When an editor, AI coding tool, or desktop Git integration runs git fetch in the background and kills it after a short timeout, Git can leave partial .git/objects/pack/tmp_pack_* files behind. If the same doomed fetch repeats every few seconds, the repository never catches up and disk usage grows until the drive fills.

Confirm the Failure Mode

First prove the disk growth is partial fetch packs, not normal Git history. Run the check from the affected repository root.

repo="${PWD}"
git -C "$repo" rev-parse --git-dir --show-toplevel 2>/dev/null
git -C "$repo" count-objects -vH 2>/dev/null

gitdir=$(git -C "$repo" rev-parse --git-dir 2>/dev/null)
if [ -n "$gitdir" ]; then
  du -sh "$gitdir/objects/pack" 2>/dev/null || true
  find "$gitdir/objects/pack" -maxdepth 1 -type f -name "tmp_pack_*" -print0 2>/dev/null \
    | xargs -0 ls -lh 2>/dev/null \
    | tail -40
fi

pgrep -af "git.*fetch|git.*index-pack|git.*remote" 2>/dev/null || true

Emergency Cleanup Boundary

Only remove partial pack files after every background Git process for that repository is stopped. If an app keeps launching a fetch every 15 seconds, cleanup alone will not hold.

1. Quit the app or disable the background upstream-status poller.
2. Confirm no matching git fetch, git index-pack, or git remote process is still running.
3. Preserve the count and total size of tmp_pack_* files for the bug report.
4. Remove only .git/objects/pack/tmp_pack_* files, not .pack, .idx, .promisor, refs, logs, or the whole .git directory.
5. Run one foreground git fetch --no-tags origin to completion so the next status check has a small delta.

Product Fix Contract

The durable fix needs two parts: cleanup after killed fetches and a loop breaker when the initial catch-up fetch cannot fit the short status timeout.

• Snapshot objects/pack/tmp_pack_* before the status fetch; on timeout or non-zero exit, delete only new partial packs created by that attempt.
• Back off hard after a timeout instead of re-downloading the same backlog every refresh interval.
• Use a longer or adaptive timeout for the first catch-up fetch, then return to a short status budget once the repository is current.
• Surface a visible degraded state such as "upstream status stale; fetch timed out" instead of silently retrying forever.
• Add a regression test that simulates a killed git index-pack and asserts size-garbage does not grow after repeated status refreshes.

I would treat this as two bugs sharing one symptom:

1. Timeout cleanup: when the status fetch is killed or exits non-zero, remove only the tmp_pack_* files created by that specific attempt.
2. Loop breaker: once a fetch timeout happens, do not retry the same full backlog every short refresh interval. Enter a degraded/stale upstream state, back off, or run one longer catch-up fetch.

For recovery, I would ask users to stop the app/background poller first, confirm no git fetch/index-pack is live, capture:

git count-objects -vH
du -sh .git/objects/pack
find .git/objects/pack -maxdepth 1 -type f -name 'tmp_pack_*' | wc -l

Then remove only .git/objects/pack/tmp_pack_* and run one foreground git fetch to completion. I would avoid any guidance that deletes .git/objects/pack/*.pack, refs, logs, or the whole repository.

Do Not Delete First

• The whole .git directory or the repository checkout.
• Valid .pack, .idx, .promisor, or ref/log files.
• App sessions, workspaces, or local changes while using disk pressure as the only evidence.
• Partial packs while git index-pack is still writing them.