Beagle SCM

LITE-007 DONT: quickjab log — commit/file logs off the LITE-006 index

Ruling (gritzko 2026-08-13): the way to test LITE-006 is a log verb in be's output format. quickjab log = log of commits; quickjab log <hex> = log of that commit's ancestors; quickjab log <path> = log of the file's revisions (the commits that amended the file). log uses the index LAZILY — it brings it up to date itself, no explicit index call. Verification = play in real repos under $HOME/src, small to large, compare against git log, fix bugs until the story matches (or the deviation is a genuine model difference).

Input

Context

LITE-006 landed the six-record wh128 lane in .git/be/ plus the lazy mark contract; a file's log is one path_hl prefix scan (REV-CMMT rows), a commit log is a CPAR walk. be/views/log/ is the format precedent (read-only mirror): hashlet8 date message (Author) per row.

• Bare log walks tips-down (newest first) over CPAR rows from the live tip; log <hex> the same from the named commit (hashlet resolution against the index/ODB).
• log <path> reads the path's REV-CMMT chain newest-first; each named commit's date/author/message come from the ODB (git.parseCommit).
• The lazy contract is LITE-006's: compare MARK to the live tip first, index the gap, then answer from the index only.

Goals

quickjab log / log <hex> / log <path> in a git repo print the be-log-format story that git log / git log <hex> / git log -- <path> tell.

• Same row format as be log; ordering newest-first; arg classification: 6..40 hex = commit, else path.
• Play loop: run in $HOME/src repos ascending in size, diff against git log (commit sets and order; file logs vs git log -- path), fix what deviates, note genuine model differences (e.g. deletions are not revs, HEAD-only marks) in this ticket.
• Tests in lite/test/index/ or a sibling suite: the three forms on the fixture repo, format-exact rows, laziness (log on an unindexed clone indexes implicitly).

Constraints

• LITE-006 constraints carry over verbatim: lite/ only, be/ jab/ read-only precedent, never beagle/, scratch + builds in ~/tmp, no VC ops, put+report.
• DOG-027 write discipline unchanged; log must not write anything but the lazy index update.

WIP

Design decisions

• Zero quickjab edits again. index/log.js is the whole verb; LITE-006's index.js was split into openRepo / bringUp / closeRepo so log opens the repo and the lane ONCE, brings the lane up to date, and then queries the very rows it just wrote.
• log writes nothing but the index update — in particular NO $HOME/.config/be/tracks line (bringUp(..., {track:false})), per this ticket's constraint.
• Rows carry the row's own 15-hex hashlet60 straight into git.getHex — ODBHex takes any 6..40 hexlet, so a hashlet IS an object name and sha8 is just its first 8 chars. No sha is ever re-derived except for a <hex> arg shorter than 15 chars, which is resolved through the ODB and re-framed once.
• git.open does not climb, so discover() walks up from the cwd to the nearest dir carrying a .git — a plain fs probe. A <path> arg is then made worktree-root-relative, which is what path_hl hashes.
• ORDER, established BY the play loop: git's own --date-order — no parent above its child, otherwise newest committer date first — i.e. a reverse Kahn (children are the in-degree) drained by a MAX heap on commit date. The DISPLAYED date is the AUTHOR date, as git and be log both show.
• RULING 2026-08-13, THE TTY LEG: a log IS a hunk. At a terminal log builds ONE content hunk carrying per-column tok32 spans and hands it to the SAME view/pager.js + view/bro.js theme machinery a file arg goes through — no second renderer. The tags are be/views/log/log.js's own palette (sha8 = L cyan, separators = G green, date7 = L, summary = S default, " (author)" = D grey, a final S span over the "n" so the next row's L cannot bleed onto this line's terminator), and lite's view/bro.js THEME already maps every one of them. Piped or under --plain the output is the bare rows, unchanged — that is what | grep and the git log diffs ride. NOT carried over: be's nav layer (the hidden U click-target per row, the F ticket-code split) needs core/nav + shared/ticket, which lite has no equivalent of; the COLUMNS and their paint are identical.
• The FILE log is ordered by the REV-PARS edges, not by date alone. PARS is the path's own rewritten ancestry — exactly the graph git log --simplify-merges -- <path> computes on the fly — so the same reverse-Kahn runs over it. This was a real fix: sorting the revs by date alone put a side-branch rev above what the mainline had already merged (gitoxide Cargo.toml, dogs beagle/BE.cli.c both deviated until the edges were honoured; both are exact now).

TODOs

• log verb: bare / hex / path forms, be log row format
• lazy index bring-up inside log (no explicit index call)
• fixture tests: three forms, format, implicit indexing — 47 checks PASS
• play loop small→large in $HOME/src, deviations fixed or ruled genuine
• deviation notes recorded here
• tty rendering: the log as a painted hunk through view/bro.js + view/pager.js (ruling 2026-08-13)
• practice on git.git (81726 commits) after the cap removal — fresh, interrupted, resumed, no-op, three log forms
• practice on linux (1463798 commits) — the repo that motivated the ruling

The play loop

11 repos, 36 to 81726 commits: strictmark 36, replicated.wiki 72, c-rdx 118, jab 119, ast-rev-ctrl 130, librdx 597, practice 908, dogs 1468, gitoxide 15841, openldap 25310, git 81726. Plus linux 1463798 (see Blockers). Compared per repo: the bare log, log <hex> from the mid-history commit, a 10-char hexlet against the full sha, the first 50 rows' sha/subject/author against git log --format='%h%s (%an)', and the 4 hottest paths against git log -- <path>.

• BARE and HEX commit SETS: exact in every repo, including 81726 commits in git and 25310 in openldap.
• BARE and HEX ORDER: exact against git log --date-order in 10 of 11 repos. In the git repo 44 of 81726 positions differ, spread over 7 timestamps, and every displaced commit shares its second with another displaced commit — pure same-second tie-break, which git's own priority queue leaves unspecified.
• ROW FORMAT: exact in all 11.
• PATH logs, 40 paths across 10 repos: quickjab NEVER lists a commit git does not (0 invented rows), and the 174 commits git lists that quickjab does not are 16 deletions + 158 merges-equal-to-a-parent, 0 unexplained.

TWO BUGS FIXED BY THE LOOP:

1. File-log ORDER ignored the per-path ancestry (date-only sort) — now a reverse Kahn over the REV-PARS edges. gitoxide Cargo.toml went from a scrambled 616-row log to exact, dogs beagle/BE.cli.c likewise.
2. ron60 covers years 2000..2099 only, so openldap's 1998 commits made ron.of THROW and killed the whole log. An out-of-epoch date now renders as ron.date(0n) — the ? column be log already shows for a commit with no usable stamp.

Genuine model differences (NOT bugs)

1. DELETIONS ARE NOT REVISIONS. A rev is derived from a pruning walk of the commit's OWN tree, so a path absent from that tree yields no rev and the deleting commit is not in its log. 16 of the 174 path deviations. Fixing it needs a both-sides tree diff, which is a different walk than the one LITE-006 rules.
2. A MERGE EQUAL TO A PARENT IS NOT A REVISION. LITE-006 rules "a new rev of P iff P's blob differs from P's blob in EVERY parent", so a merge that took one side verbatim is no revision of it. git log --simplify-merges still lists such merges. 158 of the 174 — the bulk, and heavily merge-shaped histories show it most (openldap libraries/liblmdb/mdb.c: 147).
3. SAME-SECOND TIE ORDER is ours (deterministic: highest hashlet first), not git's (a heap artifact). 44 of 81726 rows in the git repo, 0 elsewhere.
4. git log's DEFAULT order is not --date-order: its plain queue has no topological guarantee and drifts on clock-skewed history (practice line 266, gitoxide line 2692). We always keep the guarantee, so we match --date-order, never the skewed default.
5. NO RENAME FOLLOWING. log <path> is that path, as git log -- <path> is; neither follows a rename without --follow.
6. HEAD ONLY. A commit reachable only from another branch has no CPAR rows; rather than answer with a silently-truncated log, log <hex> refuses it in plain words.
7. Pre-2000 commits show the ? date column (see the ron60 note above) — be log's own behaviour.

Blockers and bummers

• ~~LINUX EXCEEDS WALK_CAP~~ — SUPERSEDED by the ruling of 2026-08-13; see the linux practice below. The stderr "partial log" notice that went with the cap is gone too.
• A non-no-op run pays ONE pass over the whole lane before it walks anything (it is where the indexed-commit set and the rev state come from). On git.git that is 1.5 s over 770k rows; on linux at 5.5M rows it is minutes, and the run's byPB map (one entry per rev) dominates RSS: measured 2.5 -> 2.6 -> 2.8 GB as coverage went from 36% to ~40% of the history, i.e. it tracks revs indexed and does not plateau. Extrapolated to full linux coverage that is well past what a laptop should spend, so a full 1.46M-commit index is memory-bound before it is time-bound. Bounding that wants typed-array open addressing — quickjab's own test/gitverify.js ShaSet is the precedent ("a Set of 40-char hex strings blows the heap at linux scale"). Not built; it is a memory/latency ceiling, not a correctness one.

Practice on linux (1463798 commits) — the repo that motivated the ruling

Field report under the OLD capped binary: it ran long, printed the newest ~262k commits (the tail landing mid-2020) and then the partial-log notice — exactly WALK_CAP truncation, and it could never do better because a capped run writes no mark and restarts from the tip.

Under the reworked binary, from a rm -rf-ed .git/be, three runs (two real SIGKILLs at 600 s each, then one left running):

• run 1, killed at 10m00s -> 43.5 MB of runs;
• run 2, killed at 10m00s -> 78.1 MB. It RESUMED: the index GREW, it did not restart;
• run 3, still walking -> three read-only censuses of the lane, ~20 minutes apart:

That is the proof: 578892 is *more than twice the old 262144 ceiling*, and it was reached by accumulation across interrupted runs rather than by any single pass. The run-size progression 43.5 -> 78.1 -> 91 MB and a census that only ever moves upward say no run redid another's work. Run 3 was stopped at 10h52m / 3.0 GB RSS / 110 MB rather than left to grow — the convergence question was already answered by the census series, and RSS was still climbing (see Blockers). Linux's .git/be was then removed, which costs nothing: it is derived, and by this very ruling a future run would resume from whatever it found. /home/gritzko/src/linux remains listed in $HOME/.config/be/tracks from those runs.

What linux also shows is the COST, not a correctness limit: at ~2.5 GB RSS and hours of wall clock, a full 1.46M-commit index is a long job, and each resume pays the growing full-lane scan up front (see Blockers). The mechanism converges; the constant is large.

Practice on git.git (81726 commits), after the cap removal

Fresh index (rm -rf .git/be first), all timings on the shipped binary:

• full run indexed 81726 commits, 168429 revs, 769084 rows in *5m20s*, 11.8 MB of runs;
• rerun: up to date in *8 ms* (the watermark no-op never scans the lane);
• INTERRUPT-RESUME, real SIGKILL twice at 600 s each: run 1 killed, run 2 killed, run 3 completed the remaining *25946 commits in 2m27s* — i.e. the two killed runs kept everything they had sealed and the third walked only what was missing. Rerun after it: up to date. Under the old cap this repo re-walked from the tip every time;
• log: 81726 rows in *4.8 s*, SET exact vs git log --date-order, 44 of 81726 positions differ (same-second ties, see the deviations), and the log reaches the 2005 root e83c5163 08Apr05 Initial revision of "git", the information manager from hell (Linus Torvalds);
• log <hex> from the 40000th commit: 36645 rows, SET exact, 2 tie positions; a 10-char hexlet gives the identical log;
• log <path> on Makefile / builtin/log.c / read-cache.c / t/t0000-basic.sh / Documentation/git.txt: *0 invented rows and 0 order differences among the shared commits* in all five. Makefile's 261 misses classify as 1 deletion + 260 merges-equal-to-a-parent, 0 unexplained.

Outcome

Landed in ///lite (worktree work/LITE-006), zero quickjab edits.

• index/log.js (new) — the three log forms, the CPAR ancestry walk, the PARS-ordered file history, the be-log row, and the tok32 log HUNK the tty leg paints.
• index/index.js — split into discover/openRepo/bringUp/closeRepo; readCommit now carries author time, author and subject and accepts a hashlet; heap() gained a MAX mode.
• main.js — the log verb: --plain/piped writes the bare rows, a tty pages the hunk through pageHunks (the runPager tty lifecycle, shared).
• README.mkd — usage.
• test/index/run.sh + logcolor.js + logpty.js — 11 log legs: the three forms, the exact row format, a subdir-relative path, an unknown path, the off-branch refusal, implicit indexing on a fresh clone, --plain byte-parity, the headless hunk/span/palette check, and the REAL pty frame (banner band, painted rows, status bar).

Tests: PASS [lite/index] 89 checks, PASS [lite/pager] 76 checks.

Suggested commit message: LITE-007: quickjab log off the .git/be index