Ambiguous Artifact ID

The artifact hash prefix 4a1e is ambiguous and might mean any of the following:

1. 4a1e5c1db2d5fbb257743210c9f746e72d4ff59eda47609c057bb5cfcf4df918 -

   • File internal/blob/inflater_test.go — part of check-in [a2bcca2535] at 2026-07-24 14:34:17 on branch trunk — content: cut sub-64KiB delta-chain expansion allocation ~18x (#145) (#150)

     delta.Apply's one-time capacity upgrade (#127) only engages above the 64 KiB threshold, so it is a no-op for the typical source file under 64 KiB. But below the threshold Apply already sizes its output buffer exactly, so there was never a 5x overhead there to remove -- extending the threshold buys nothing. The real per-link cost of a chain walk was elsewhere, and a profile of a plain Expand of a deep sub-64 KiB chain shows it: a fresh ~32 KiB zlib history window allocated per delta load (~27% of bytes), one full-size Apply output buffer per link (~16%), and a fresh inflate buffer per link. All three are O(depth) allocations for a single cold Expand, which is O(depth), making a full-history walk O(n^2).

     Attack the per-link constant inside the one choke point every expansion goes through, content.expandChain, leaving the on-disk chain shape untouched:

     - delta.ApplyInto(dst, source, delta) reconstructs into a caller-supplied buffer, reusing its capacity. Apply is now ApplyInto(nil, ...), unchanged. A reused buffer's capacity is proven prior work, not a wire-header claim, so it is a safe starting size; the anti-DoS growth path (growOutputCap, keyed off len(delta) not the targetLen header) is preserved for buffers a target outgrows. - blob.Inflater loads a run of blobs through one zlib reader, reset per blob instead of rebuilt, paying the ~32 KiB window setup once per chain. Each Load still returns a freshly owned buffer, so no returned-slice-aliasing contract leaks to callers. - expandChain's plain-Expand replay (put == nil) ping-pongs two output buffers -- each link's target reuses the buffer from two links back, whose content was already consumed as the previous link's source, so dst and source never alias. The caching path (put != nil) is unchanged: put takes ownership of every materialized buffer, so those cannot be reused underneath it, but it still shares the reused zlib reader for its delta loads.

     Measured on Apple M4 Pro, BenchmarkExpandOldestVersion, median of 3, 40x:

     sub-64 KiB (~26 KB file), Expand of the oldest revision: depth 11: 883 KB -> 232 KB/op (3.8x), 1.12 ms -> 0.90 ms depth 49: 3.57 MB -> 341 KB/op (10.5x), 4.55 ms -> 2.03 ms depth 199: 14.2 MB -> 772 KB/op (18.4x), 14.84 ms -> 7.25 ms

     >64 KiB (~206 KB file), no regression -- ping-pong + reader reuse help it too: depth 11: 4.11 MB -> 1.27 MB/op (3.2x), 3.40 ms -> 2.74 ms depth 49: 16.5 MB -> 1.81 MB/op (9.1x), 13.02 ms -> 7.69 ms depth 199: 65.2 MB -> 3.92 MB/op (16.6x), 46.3 ms -> 26.6 ms

     Sub-64 KiB allocation is now near-flat in depth instead of linear in depth*targetLen. expand_reuse_test.go guards the reuse; delta and blob gain allocation-reduction unit tests. (user: [email protected], size: 2538) [annotate] [blame] [check-ins using]

2. 4a1e63306cc484bf4203cb9a265e683e91a8fd1dbffa594cfe9841418a221ad8 -

   • File internal/xfer/decode.go — part of check-in [d3fb5397c8] at 2026-10-13 15:15:43 on branch main — fix(sync): answer a client clone_seqno with bad command; make Clone's phantom pull opt-in (#427)

     * fix(sync): answer a client clone_seqno with bad command; make Clone's phantom pull opt-in

     Two deliberate #255 deviations from sync-protocol-01 move to conformance.

     SP-5.2-6: the server now answers a client-sent clone_seqno with "error bad command" and processes the cards after it, as Section 5.2 requires for a reply-only card and as fossil's page_xfer does.

     SP-8.2-5: Clone now sends nothing after clone_seqno 0 and its cleanup round, so by default it leaves the phantoms a clone produces in place, as fossil(1)'s clone does. The follow-up pull that fetched them is now opt-in through CloneOpts.PullPhantoms, whose doc comment says enabling it departs from Section 8.2.

     Both cases leave the sync deviations map. Tracked in #424.

     * fix(sync): quote a client clone_seqno as received in bad command; keep DST coverage of the opt-in pull

     Tracked in #424. (user: [email protected], size: 25246) [annotate] [blame] [check-ins using]