LOG-003 HIGH: be log row order is STORE-LAYOUT-DEPENDENT — a be get be://… clone renders the SAME history jumbled (tip row is an ancient commit, dates non-monotonic)

be log over a be://-cloned store lists the SAME commit closure in a jumbled order: the first (tip) row is an ancient commit, not the cur, and the dates run non-monotonic (06Jan, 02Mar, 19Oct24, 28Mar25, 13Apr, 31Aug24, 07May, 11Jun, 12Jun, 03Apr…). The SAME binary over a natively-built store with the SAME closure renders correctly newest-first / time-descending. So the log walk's ROW ORDER depends on the physical store layout (the order objects/graf landed during the wire fetch), not solely on the DAG — a clone scrambles the listing. Distinct from LOG-001 (non-spine greying); this is the ordering of the spine listing itself. Method Issues.

Input

Context

Goals

Constraints

WIP

Design decisions

TODOs

-~ JS be/views/log/log.js not present in this working tree (the be/ JS tree referenced

by LOG-001 is not checked out here) — could not cross-check; flagged for the JS owner.

Blockers and bummers

Outcome