New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Oxidize Radicle-Git #1319
Comments
This is exciting! Something I'd like to point out is that replacing The heaviest lifting and biggest concern for a first task is the fact that we're still using the |
Thank you for clarifying that. From my experience, using And I'd definitely love to finally come up with a fetch-API that is easy to use but not unnecessarily limiting, and can thus work for you as well. If that was the case, I think you could start tracking a more recent version which might ultimately pay off. If you would link the latest code that uses the Thanks again! |
Compatibility in which sense? :) In my mind, the
Interesting. I can have a look again because, admittedly, it was a while that I looked and then got swept away by other tasks.
I should have taken notes when I explored trying to use the updated version, but unfortunately my foresight is not 20/20 😅 So the main entry point to using the gix fetch code are the following helpers: The I think the best way to understand how we use the delegate approach is by describing the high-level flow. The important context is that there are two, special
With this in mind, the protocol is essentially a series of stages where we fetch a set of this data and ensure some data validity. The state is kept in a type called The stages are run in the following order:
All of this happens over a long-lasting connection, so we only perform the handshake step once. The handshake payload is passed down to each of the The protocol finishes by signalling to the other end that it's done and it can cease sending upload-packs. The fetcher can then validate all the data it received checking signatures and ensuring that the data is in a consistent state, applying all the updates to the refdb if it's all consistent. I hope that makes sense, but please let me know if I can elaborate on any points! |
Thanks a lot for writing all this down! All this sounds familiar, particularly the multi-step process of downloading packs for different refs. If I remember correctly, the server-side is a plain git server over QUIC transport, which supports git protocol V2. That allows to use a single connection for multiple requests/commands, which are tuned according to the needs, with each stage informing what the next stage can or should do. My goal here would be to see how I can transform the code away from the Delegate approach to the new command-oriented API, and I think I could consider that successful once the test-suite passes again. This also means that Once successful, this should allow you to track the latest versions of these plumbing crates, and since I do it I would make the API adjustments necessary to support this case as well. This probably also means you don't have to recheck the I probably won't get to it very soon, but it's on my list now and I will make it priority once the last stage of |
I should have also linked the
Aye, that makes sense and resonates with my memory of trying to use
Hahaha thank you for saving me that time up-front 😄
Sounds good! Ping me if there's anything I can help with when you get around to it. |
We're no longer using QUIC, we're using a custom framed protocol over TCP, though I don't think it's so relevant since the fetch code just works with generic writers. |
I see, thanks for the update!
Speaking off, the employment-idea at GitButler fell through, but I am
doing some freelance work for them to integrate `gitoxide`. Internally
I'd reconsider employment in two years or so, when Gitoxide is hopefully
feature-complete (in terms of git2 parity at least), and stable.
A long road ahead, but an even longer behind :D.
…On 3 Apr 2024, at 21:56, Alexis Sellier wrote:
We're no longer using QUIC, we're using a custom framed protocol over
TCP, though I don't think it's so relevant since the fetch code just
works with generic writers.
--
Reply to this email directly or view it on GitHub:
#1319 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Here is the repository: https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z6cFWeWpnZNHh9rUW8phgA3b5yGt
Required Features
Delegate
system. (see this comment for all the details on where to look; also check the server side of things for reference)More Analysis TBD
Preferences
git-ref-format
- typesafe/statically analysed ref handlingradicle-git-ext
for better tools to work with commitsNotes
The repository contains a lot of extra-functionality that also isn't present in
git2
. This should probably be available fromgix
as long as it's not Radicle specific.git2
ingix
gix
where possible, slowly replacinggit2
git2
once there is nothing left.The text was updated successfully, but these errors were encountered: