UPSTREAM PR #2465: feat: barebones initial server-side upload-pack implementation

[loci-dev]

Note

Source pull request: GitoxideLabs/gitoxide#2465

tl;dr

I am building a git forge, needed server-side git functionality, found gitoxide, liked it, decided to build on it. This is me attempting to upstream it.

---

Hey!

Sorry if me opening this PR out of the blue and is not the process but I have recently started building a small toy git forge in Rust for some fun and when it came to the "git" part I came across gitoxide and really liked it. However, I noticed that the server-side support was not ready for me to build what I wanted, this is my assumption from reading the code anyway.

So I was interested enough to just try to implement it myself and this is what this PR contains. I attempted to go as shallow as possible as to have something to maybe discuss if this is something gitoxide is interested in before I got carried away into all the nitty gritty. That being said it does do some (very little) real stuff:

What is here:

• gix-transport: Added server-side connection handling: connect message parser and Connection struct
• gix-protocol: Added server-side upload-pack: ref advertisement writers, wants/haves parser,
  ACK/NAK writers, and upload-pack orchestrators for both protocol versions
• gix-serve: New crate wiring it together: ref collection from a ref store, pack generation from wanted
  objects, and a top-level serve_upload_pack() entrypoint

There are a lot of caveats though...

Caveats:

• Ignoring "haves" so servers always send all objects reachable from wants
• Ignored capabilities for now in the actual serve implementation - they do get parsed though
• No add-on features supported i.e. shallow-clone etc
• The pack generation is as naive as it gets, just an unthreaded implementation

However despite being pretty far from done I have an ssh server in my git forge able to serve git clone requests - this can be seen here: https://github.com/JamesPatrickGill/steid

---

I am very open to guidance and getting this ship shape if you see value. I attempted to match conventions from other crates in the repo as closely as possible.

[loci-review]

Overview

Analysis of 27,956 functions across two binaries shows negligible performance impact. Modified: 473 functions (1.69%), New: 1,578 (server-side features), Removed: 1,578, Unchanged: 24,327.

Binaries analyzed:

• target.aarch64-unknown-linux-gnu.release.gix: -0.002% power consumption (804,433 → 804,420 nJ)
• target.aarch64-unknown-linux-gnu.release.ein: -0.013% power consumption (299,315 → 299,277 nJ)

Function Analysis

All analyzed functions show compiler-level optimizations with no source code changes:

• gix_protocol::Ref::from (gix): Response time -3.82ns (-2.2%), throughput -1.66ns (-2.2%). Protocol handshake conversion with improved instruction scheduling.

• clap_builder::format_error (ein): Response time -105ns (-0.004%), throughput -4.91ns (-4.7%). CLI error formatting with minor optimization in error path.

• clap_builder::Parser::parse_from (gix): Response time +15.5μs (+0.017%), throughput +4.72ns (+2.36%). Startup-only CLI parsing with diffuse increases across argument processing.

• gix_worktree::Statistics::serialize (gix): Response time -2.94ns (-0.11%), throughput -2.35ns (-2.61%). Derive-based serialization with compiler optimization.

Other analyzed functions showed sub-10ns changes in error handling and statistics serialization. None of the modified functions are in performance-critical paths (object lookup, pack operations, diffing, status computation). Changes result from binary layout adjustments and LLVM optimization passes during recompilation.

The 12 commits add comprehensive server-side Git protocol support (gix-serve, upload-pack V1/V2) with minimal impact on existing client operations.

🔎 Full breakdown: Loci Inspector
💬 Questions? Tag @loci-dev

[loci-review]

The flame graphs show the transformation from trivial 22ns execution (base) to complex 9.4ms execution (target) with UI rendering operations (pane, headline, render functions) consuming 75% of execution time. This indicates prodash TUI rendering is incorrectly linked into thread-local storage access paths in the ein binary.

Additional Findings

Commit context: 14 commits by JamesPatrickGill add server-side Git protocol support (gix-serve crate, upload-pack orchestration, ref advertisement, pack generation). Changes represent intentional feature expansion rather than refactoring.

Architectural observation: The ein binary-specific thread-local regression suggests build configuration or feature flag differences between gix and ein binaries. Gitoxide's architecture explicitly avoids thread-local rendering (uses Arc-based sharing with separate UI threads), making this regression particularly concerning as it contradicts design intent.

🔎 Full breakdown: Loci Inspector
💬 Questions? Tag @loci-dev