Radicle about gitoxide

[Byron]

You know how great it is to have you here thanks to the gloomy language in the keybase chatroom, so this message is just for the world to see :).

That said, let's get to it!

Remote capabilities would be our highest priority, being able to fetch changes from a peer
in our case and the peer responding with the changeset.

I believe this is feature complete and you can fetch everything that 'git' can fetch.

The Ref DB would be our next highest priority.

It's not implemented except for verifying ref names, but getting what you need there will be quite straight forward and a good exercise to get started with the code base. Of course I am happy to assist there, having implemented it once myself.

Followed by local capabilities, we're happy to use libgit2 here during a transitionary period.

This is generally how I thought it could be done as well, use libgit2 for everything while you can't use gitoxide for it, and choke it out in order of pain.

As I mentioned above, the fetch exchange
would be top of our list. Maybe you could flesh out what's complete here, what's missing, and where
we could start looking in the code-base to understand this better.
To elaborate on our needs in this area, we need to implement our own transport
layer, so we'd be interested in what the gitoxide API looks like here.

Let's setup a zoom call for 90 minutes to 2h and I will guide you through everything you want to know. This is most certainly more productive when done interactively.

We will have a lot of refs, which we constantly read and update. Eventually, we will want a
"real" database, but if we keep using libgit2, we would have to teach it to use a custom backend. As
a middleground, if gitoxide supports "packed refs" (that's a single file containing all the refs),
this would already be an improvement (that's assuming libgit2 loads the refs lazily).

Since you are the first implementing ref reading and writing, you would be able to define how it should be. I am sure we find something that's both simple while supporting what you need. My suggestion is to keep it 'dumb' for now and wait until the API settles and packed-refs get too slow. Then a trait might do the trick. My first thoughts on this, I am happy to discuss this with you in our session.

For reference handling, we need to be able to read references, perform commits, and compute merge
basing. This functionality is necessary for our handling of documents on the network.

This would probably be happening in in git-repository, and once git-ref is implemented you should be ready to traverse the commit graph and generally do more useful things.

The V2 implementation

I am probably failing to understand what exactly you are talking about but can tell you that much: The git-protocol crate contains everything you are looking for, and I believe the client has all control it could ever want as the 'base' implementation truly only takes care of doing the necessary communication while the content is controlled by the implementor of a trait.

As pack-send is not implemented, there is no server side to this in gitoxide yet and you could be the ones to define how this looks like, giving you all the control you need beyond of what's needed for a standard git client.

We're excited about the prospect of using gitoxide and being able to contribute to it, however,
we've only got so much person-power at the moment. So this is a good first step in figuring out how
much work is involved. After that, we can work out how much time we delegate to helping out on the
project.

Yes, let's make sure your work is surgical and efficient - best to talk in person and I will reach out to you in keybase to set something up.

It's going to be great 👍 !

[Byron]

I think git-config was accidentally skipped. Even though the read and write API is sketched out, the parser is missing. #31 is tracking the issue.

[crutchcorn]

I'm also working on the parser right now, as we speak. I'll see what type of progress I can get done over the weekend - dangerous (the parser lib we're wanting to use) seems pretty straightforward, I'm just reading through the git config spec from Git's C source code to make sure I get 100% coverage.

I'll make sure I write tests for that config parser as well

[Byron]

That's so great to hear, thank you! If there is anything stopping you, please don't hesitate to reach out in our realtime channel for quick support.