Radicle

[FintanH]

Hey @Byron,

I met with @xla and @kim to discuss gitoxide and our needs in radicle-link.

We landed in a high-level priority list as follows:

• 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.
• The Ref DB would be our next highest priority.
• Followed by local capabilities, we're happy to use libgit2 here during a transitionary period.

Remote capabilities

Looking through the checklist from the README, we saw that one part of the fetching story is
complete but we would need pack-send which is unchecked. 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.

Reference DB

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).

Local Needs

Reference Handling

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.

Git Config

We use the git config in a couple of places currently. One way is to track remotes and the other is
for configuring working-copies for fetching changes. Since we can rely on libgit here, it's lower
priority.

Notes and Questions

The V2 implementation

Because in v2, the server doesn't send all the refs unsolicited, but the client requests them
explicitly, and can filter by prefix. It is also, afaiu, that the "ref-in-want" feature would allow
us to request refs across namespaces, without jumping through hoops to make the server ref
advertisement match what we are likely going to fetch (we can compute all refs we want to fetch up
front).

Somewhat relatedly, libgit2 currently insists to only update (a subset of) the refs the server
advertised, at the exact oids the server advertised -- what we would want is a bit more control over
this:

Say we have refs/remotes/XYZ/rad/foo, for which the remote peer advertises that its tip is
abcde. We know, however, that XYZ signed a tip xyz09 which is an ancestor of abcde. We'd like
to ask the remote end for xyz09, and if that object is in the packfile, we'd update
refs/remotes/XYZ/rad/foo locally to this. Currently, if the remote end is ahead, we would not
update the ref at all.

Questions

1. We saw a check box for "Write all data types" and we were wondering what this meant?
2. The checklist is useful to understand at a high level what you've completed but I think we'd like
   to get a better understanding of what's more complete, what's still in progress, and what hasn't
   been started.

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.

[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.