Pure Pony Git Client for Corral

[SeanTAllen]

Motivation

Corral currently shells out to the git CLI via ProcessMonitor for all git operations. Replacing this with a pure Pony implementation removes the runtime dependency on git being installed, which matters for a package manager:

• Bootstrapping: A dependency manager shouldn't itself require external tools to be pre-installed. A self-contained binary is easier to distribute and adopt.
• Consistent behavior: No variance from user's git version, git config, or PATH/environment differences.
• Structured errors: Library calls give real error types instead of exit codes and stderr parsing.
• Single binary deployment: No runtime dependencies beyond what the Pony runtime already needs.

Replacing git with FFI bindings to libgit2, zlib, or OpenSSL would just trade one external dependency for others. The goal is a fully self-contained implementation. The one accepted external dependency is SSL (via LibreSSL/OpenSSL) for HTTPS transport — this can be statically linked on all platforms (LibreSSL on macOS/Windows, musl builds on Linux).

Current Git Usage in Corral

Corral uses exactly 5 git commands (all in corral/vcs/git.pony), all read-only:

Operation	Command	Output Parsed?
Clone	git clone --no-checkout https://... path	No (exit code only)
Fetch	git -C path fetch --tags	No (exit code only)
List refs	git -C path show-ref	Yes — extracts tag names
Reset	git -C path reset --mixed rev	No (exit code only)
Export files	git -C path checkout-index -f -a --prefix=path/	No (exit code only)

The flow: clone/fetch a repo -> list tags -> resolve version constraints -> reset to chosen revision -> export files to workspace. Corral is strictly a consumer of git data, never a producer.

Implementation Components

1. Pure Pony SHA-1

Effort: Small (~100-200 lines)

Well-specified algorithm, just bitwise operations on U32 values. Performance is adequate for corral's use case (hashing individual git objects, not bulk data). The spec is ~10 pages with no ambiguity. There may be an existing implementation in ponylang/ssl that could be reused.

2. Pure Pony Inflate (zlib decompression)

Effort: Medium-large (~800-1,200 lines)

The biggest foundational piece. Git uses zlib to compress every object. Corral only reads git data, so only inflate (decompression) is needed, not deflate.

Sub-components:

• Huffman table decoding (~200-300 lines)
• Fixed and dynamic Huffman tree construction (~200-300 lines)
• LZ77 sliding window / back-reference copying (~100-150 lines)
• Block header parsing: stored, fixed, dynamic (~100-150 lines)
• Adler-32 checksum (~30-50 lines)
• Top-level stream framing / zlib header (~50-80 lines)

Reference points: miniz's tinfl_decompress is ~500 lines of dense C with heavy macros. Go's compress/flate reader is ~800 lines. Pony would likely land in a similar range. Well-specified by RFC 1951 with no ambiguity.

3. Git Smart HTTP Protocol

Effort: Medium

Layered on top of vendored ponylang/courier HTTP client library:

• /info/refs?service=git-upload-pack capability advertisement
• Have/want negotiation
• Pack data response with sideband demultiplexing
• HTTPS-only (matches corral's current behavior)

Courier and its dependency tree will be vendored into the corral repo so that corral does not require itself to bootstrap.

4. Packfile Parser

Effort: Medium-large

The most complex git-specific binary format:

• PACK file header and object entries
• Object types: commit, tree, blob, tag
• Delta objects: OFS_DELTA and REF_DELTA
• Delta chain resolution (recursive)
• Depends on inflate (Setup CI #2) and SHA-1 (Switch to the standard Pony BSD license #1)

5. Git Object Database and Ref Management

Effort: Medium, well-documented formats

• Loose object storage: SHA-1 hash -> .git/objects/xx/yyyy... files
• Pack index (.idx) files for object lookup in packfiles
• Object reading: decompress -> parse type/size header -> return content
• Ref reading: .git/refs/tags/* files + .git/packed-refs parsing
• Ref reading is the easiest part — just file I/O and string parsing

6. Index and Tree Operations

Effort: Medium

• Git index file format parsing (v2/v3/v4)
• Tree object walking (parse entries: mode, name, SHA-1)
• Reconstruct index from a commit's tree
• Extract blobs to filesystem with correct paths and permissions

Estimates

Component	Effort	Lines (rough guess)
SHA-1	Small	100-200
Inflate	Medium-large	800-1,200
Smart HTTP protocol	Medium	500-800
Packfile parser + deltas	Medium-large	800-1,200
Object DB + refs	Medium	400-600
Index + tree + checkout	Medium	400-600
Total		~3,000-4,600

A real project but not an unreasonable one, especially since corral only needs the read side of git.