.be blob → fsck fails
Pushing 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 inthe committed tree object, so the tree has a dangling reference once the walk drops it.
keeper/WALK.c DPATHVerify) skips .be, so its blob isomitted from the generated pack.
git fsck/git-receive-pack: missing blob object. Existingremote (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 storeanchor; 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.
gitignore semantics for .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, confirmfailing pre-fix.
mounts. Independent of POST-021's BASS/BNOROOM fix.