Beagle SCM

GIT-010 MED: pack-log index-emit — feed/scan emit (sha→offset) into a provided buffer

The pack-log does NOT maintain an index. Its feed and a scan EMIT (sha→offset) entries into a caller-provided buffer (if given); sort / merge / persist / query is entirely the caller's. Native core in dog/git (shared by keeper + the git.pack JABC binding). Method: Issues.

Input

Context

• The dog/git pack core (PACKu8sFeedObj / PACKResolveOfs / PACKRecordEnd,

  GIT-007) is the shared format floor — no pack-log logic in consumers.

• git.pack (the JABC binding, JS-024) wraps that core but emits NO

  sha→offset today (per js/INDEX.md the index "stays in the caller").

• Design (the user's framing): the pack-log is an ENTRY PRODUCER into a

  caller buffer, not an index owner — exactly the tok.parse(…, out?) / delt.apply(…, out) shape. The caller pipes entries into a JS-022 abc.index (wh128); the rest is up to the caller.

Goals

• A dog/git scan/index-emit: walk a pack, resolve each object, git-sha it,

  emit (sha-hashlet60|type, offset) into a provided buffer (Bwh128).

• Index-on-append: feed optionally emits the just-fed object's entry into

  the same buffer — cheap (hash the content you already hold; no resolve).

• git.pack exposes both with an optional out buffer; a JS test pipes the

  entries into an abc.index and looks up sha → offset.

Constraints

• Native core in dog/git (shared, per the topic architecture) — reuse

  PACKResolveOfs (resolve) + dog/git sha1 + GITTypeName (the <type> <len>\0 git object framing). SINGLE-pack, NO keeper coupling, NO fork parallelism (the heavy multi-pack/ingest path stays in keeper/UNPK).

• Buffer-feed shape mirrors tok.parse/delt.apply: emit into the caller's

  region, hold nothing (JABC rule #4). Don't change the pack format.

• Emit wh128 (key=hashlet60|type, val=offset) to match the keeper puppy

  registry + the abc.index wh128 lane, so the caller can merge directly.

WIP

Design decisions

• (open) The reindex resolves deltas; a JS-over-cursor loop would re-inflate

  bases O(objects×depth) (the index design pass), so the SCAN is NATIVE (one pass, shared apply state) — keeper/UNPK.c::UNPKIndex is the algorithm REFERENCE (model the single-pack core on it, minus parallelism + keeper).

TODOs

• Repro-first: a dog/git test + a git.pack JS test — build a pack with

  raw + OFS_DELTA objects, scan → entries, assert each (sha, offset) resolves byte-correct; pipe into an abc.index and assert sha→offset lookups; assert index-on-append == a full reindex.

• Implement the dog/git scan-emit (+ feed-emit); bind via git.pack;

  update dog/INDEX.md + js/INDEX.md / js/API.md.

Blockers and bummers

• If the native scan needs keeper/UNPK machinery or the C balloons beyond a

  single-pack emitter, STOP and report — keep it a small dog/git core.

Outcome

• LANDED 090658bb (2026-06-21): dog/git/PIDX.{h,c} — `PIDXScan(pack, out,

  …) walks one OFS-only pack, resolves via PACKResolveOfs, git-shas, emits wh128 (hashlet60|type → offset) per object into the caller's Bwh128; PIDXFeedEmit = cheap index-on-append. Modeled on UNPKIndex, stripped of keeper/parallel/REF/ingest (a stray REF → PACKREF). Hoisted the key packing into shared dog/WHIFF.h::WHIFFKeyPack (keepKeyPack now an alias). git.pack: pack.scan(out) + pack.feed(…, out?). C PIDXtest + JS JABCpackidx (entries → abc.index → sha→offset`; append == reindex) red→green; full ctest 345/345, ASAN/LSan clean. Caller pipes into JS-022.

• Deferred: converge keeper UNPKIndex onto PIDXScan (its parallel / REF /

  ingest paths exceed this single-pack core) — a follow-up ticket.