Skip to content

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

Open
James Gill (JamesPatrickGill) wants to merge 3 commits intoGitoxideLabs:mainfrom
JamesPatrickGill:main
Open

feat: barebones initial server-side upload-pack implementation#2465
James Gill (JamesPatrickGill) wants to merge 3 commits intoGitoxideLabs:mainfrom
JamesPatrickGill:main

Conversation

@JamesPatrickGill
Copy link
Copy Markdown

@JamesPatrickGill James Gill (JamesPatrickGill) commented Mar 10, 2026

tl;dr

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

I'm happy to rework it and take any feedback!


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.

@JamesPatrickGill James Gill (JamesPatrickGill) changed the title A barebones initial server-side upload-pack implementation feat: barebones initial server-side upload-pack implementation Mar 10, 2026
Copy link
Copy Markdown
Member

@Byron Sebastian Thiel (Byron) left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, I had a first brief look and hoped you could squash this work into one commit per crate, in order of dependency?

Thanks a lot!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I ramp up for review, could you remove the .tar file so I can add them myself (or chose to not add them at all)?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for getting back!

I've just done those suggested changes and pushed them.

Understand this might be far from the desired state but very happy to put the time in to get the feature (and also figure out what the contribution looks like to gitoxide haha, the first is always hardest)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants