.be blob → fsck failsPushing a beagle history to a BRAND-NEW / empty git remote produces an inconsistent
pack: the committed root trees carry a .be entry (the store anchor — gitignored yet
recorded in the tree object), but the pack walk (keeper/WALK.c DPATHVerify)
deliberately SKIPS .be, so the blob the tree entry points at is never written.
A fresh remote has no copy, so git fsck / git-receive-pack rejects the push with
missing blob object. Against any remote that already holds the blob (every
incremental fast-forward — the normal path) it is harmless, so it only bites a fresh
or empty remote. Found while fixing POST-021 (the push BNOROOM); isolated there by
using a .be-free synthetic history for the regression test, so it is unrelated to
that fix and gets its own ticket.
The tree references a blob the pack refuses to ship.
.be entry (store anchor). It is gitignored but present in
the committed tree object, so the tree has a dangling reference once the walk drops it.keeper/WALK.c DPATHVerify) skips .be, so its blob is
omitted from the generated pack.git fsck/git-receive-pack: missing blob object. Existing
remote (already has the blob) → harmless; hence only fresh/empty remotes fail.A fresh-remote push yields an fsck-clean pack — no dangling tree references.
.be in the committed tree (it is the gitignored store
anchor; arguably never belongs in a tree), OR include its blob in the pack when
the tree references it. Pick one and make tree-vs-pack consistent..be-bearing history to a FRESH bare git remote, assert
exit 0 + git fsck clean + remote advances..be in the working tree. Couples to the store-anchor
layout (SUBS .be/.dogs handling).(pending — decide: drop .be from trees vs ship its blob)
.be becomes a tree entry (the commit/tree builder; keeper POST /
DPATH) and why DPATHVerify skips it on the pack walk..be tree entry, OR pack-include it) and apply.git fsck test, confirm
failing pre-fix.