feat: Add upload-pack for server - #2887
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9a356a3dba
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
9a356a3 to
e7712be
Compare
Co-Authored-By: Oz <oz-agent@warp.dev>
…ct message parsing Add gix-transport::server with primitives for accepting incoming git protocol connections: - ConnectRequest: parsed client connect message (service, path, host, protocol) - parse_connect_message(): parses git-proto-request format from raw bytes - Connection<R, W>: bundles packetline reader + writer + connection metadata - Connection::new(): for HTTP/SSH where setup is handled externally - accept(): reads first packetline and returns a ready Connection The blocking_io submodule is gated behind the existing blocking-client feature flag. The base types and parsing are always available. Co-authored-by: Kiro <kiro@amazon.com> feat: add async server-side transport module Add gix-transport::server::async_io with the async equivalent of the blocking server connection primitives: - Connection<R, W>: async packetline reader + writer + metadata - Connection::new(): for HTTP/SSH where setup is external - accept(): async version reading first packetline to establish connection Gated behind the existing async-client feature flag. Integration tests mirror the blocking_io test suite. Co-authored-by: Kiro <kiro@amazon.com>
e7712be to
37c53fe
Compare
Ethan (ethanlabstack)
changed the title
Introduce an `experimental` Cargo feature on the `gix` crate that gates an in-process `BuiltinUploadPack` transport and `RepositoryDelegate`. When activated via `--builtin-upload-pack` on clone/fetch for file:// URLs, this drives `gix-protocol`'s `serve_v2()` directly instead of spawning an external `git-upload-pack` process. - Add `experimental` feature to `gix` (enables `gix-protocol/blocking-server`) - Forward feature in workspace root, included in `max`/`max-pure` only - Implement `BuiltinUploadPack` transport in `gix/src/transport/` - Add `--builtin-upload-pack` CLI flag to clone and fetch commands - Wire flag through gitoxide-core into the connection path - Add journey test validating equivalence with external upload-pack - Early-exit error when flag is used without experimental feature compiled in Co-authored-by: Kiro <kiro@amazon.com>
37c53fe to
3075ca5
Compare
Ethan (ethanlabstack)
changed the title
|
Thanks for sharing! And while I am excited to see a server-side happening with the help of This means, please have a go in your fork, and as the implementation stabilizes, please do upstream primitives and QoL fixes (and actual bug-fixes) as you see fit. These I can review and merge. Nowadays maintaining a fork/patchqueue is very straightforward, so I think this should be good for all parties involved. |
Yeah it's a massive PR and I wondered how long it would take for you to process it! So, lets explore this a little. Firstly, I have three distinct commits - the last two entangle existing code, and I did because the previous PR had/asked for them. The first commit - well, that is the meat, and that is all new code. So, I can maintain a fork long-term (but merging Cargo lockfiles is not that fun I did that by hand) - if so, I'll just dump the last two commits and keep the upload-pack warm. The real question - the amount of code is not going to shrink, it's more likely to grow if I keep it. At what point would you consider merging it back into the mothership? Is there some sort of rubric I can aim for ? Thx |
I heard one can use
I don't know - I think I am busy to the end of this year with all the other parts that are missing to get Git3 compatibility and at least a |
2 participants
Thanks James Gill (@JamesPatrickGill) for the great start on your PR #2465 .
This is a full replacement, as I have taken a different architectural direction in terms of the layers.
The gix-protocol library is all I need, as I will be handling the HTTPS and SSH termination in the app.
NOTE: I have added a full async version of upload-pack - Sebastian Thiel (@Byron) not sure which way you'd prefer to go here, it could just be like the receive-pack and be pho async - terminating async nicely but then having a common blocking backend.
ALSO I have not added V1 support, happy to add if you require - my research was that we'd be hard pressed to find a client in the wild only supporting V1 these days.
I have added a server in the gix-transport for convenience. It is fairly trivial from there to round that out with gix porcelain for someone who might want to run a server only using gitoxide. I'm not sure what that use case would be so haven't added it. I also haven't given it much attention as I'm not using it.
I've taken on board the comments from #2465 and hope I've landed the 'experimental' flag where you wanted it.