glm-5.3-flash
a3cdef909b
- Cargo workspace with 5 sub-crates: alkgit-core (storage), alkgit-transport (smart protocol), alkgit-http, alkgit-ssh, alkgitd (binary); sha1 pinned through the gix stack, sha256 passthrough feature - docs/research/: vision, gitoxide alignment, alk stack fit, server-side protocol inventory, license/reference policy, POC plan - AGENTS.md: conventions mirroring alkcall (no comments, thiserror, tokio, no secrets on wire/at rest, visible-surface=authorized-surface, gitoxide-only serving path, bounded resources, registry-resolved repos) Verified: cargo build, clippy -D warnings, fmt, test, check --all-features
3.2 KiB
alkgit POC Plan
POCs live in research worktrees (.worktrees/research/<task-id>/) per
sdd_process phase 0, or as scratch experiments outside the main workspace
tree if a worktree isn't available yet. Each POC records: hypothesis,
method, result (proceed/pivot/block), and what it changes in the research
docs.
POC-1: pkt-line over alkcall BiStream
Hypothesis: a full V2 fetch handshake (ls-refs + one fetch round)
between real git CLI (as client, git clone/git fetch) and a Rust
listener that bridges alkcall BiStream to gix-packetline's async codec
can be completed.
Method sketch: alkcall Connection accepted over a local stream; spawn
a handler that receives a BiStream; wrap read_half/write_half in the
pkt-line async reader/writer; advertise V2 capabilities with honest feature
list; parse command=ls-refs, emit refs from a fixture repo (created with
gix), flush. Client side: git -c protocol.version=2 clone against a
local bridge (POC can start with plain tcp and only simulate the alkcall
side if alkcall dialing adds friction — the alkcall-fit part can be tested
with Connection::from_stream).
Success: git prints its ref advertisement fetch result without error; all framing validated against real git's parser (the strictest pkt-line validator available).
Risks: gix-packetline async-io feature uses futures-io traits —
confirm alkcall stream halves implement AsyncRead/AsyncWrite
compatibility (they should, being tokio io objects; may need a thin adapter).
POC-2: server-side pack generation
Hypothesis: given a fixture repo and a want/have set, we can produce a
valid pack stream in memory that git verify-pack/git unpack-objects
accepts, using one of:
a. gix-pack::bundle::write into a temp dir then read the file back
(correctness baseline), or
b. gix-pack::data::output::bytes fed by an odb object walk (streaming).
Method: build fixture repo via gix API or a scripted git (fixture
creation may shell out to git — only serving-path must be git-binary-free).
Try (b) first; fall back to (a) to establish the correctness baseline.
Success: git clone from a bridge that serves the generated pack
completes and git fsck passes in the clone.
Decision to make: streaming composition that doesn't materialize the whole pack in memory for large repos — record memory behavior for a 10k-object repo at minimum.
POC-3: smart-http shape through alkhttp
Hypothesis: alkhttp can serve GET /info/refs and stream a POST body
(ingest without full buffering) for git-receive-pack.
Method: minimal alkhttp service exposing a fake
/repo.git/info/refs?service=git-upload-pack and
/repo.git/git-upload-pack wired to the POC-1 bridge; run real git clone http://... against it; measure whether alkhttp's request-body API streams
or buffers (inspect/measure, not guess).
Success: real git clones over http; documented answer on body streaming for receive-pack sizing.
Sequencing
POC-1 first (the BiStream/packetline fit is the load-bearing assumption). POC-2 next (the crux of fetch). POC-3 last (http shape). Each POC updates the corresponding research doc with results and a proceed/pivot/block note.