client push to remote

[Byron]

As in git push.

Tasks

• git-odb

  • [x] basic pack generation based on tree-diff or tree-traversal

• [x] Traversal (as building blocks to feed pack generation)

  • [x] Traverse a commit graph (look around to see what's common, if in doubt walk back the commit graph and see how to deal with branching)
  • [x] Traverse trees
  • [ ] best-fit delta objects creation using the imara-diff, or maybe something custom if that's what git does.

• git-protocol

  • [ ] ReceivePack logic for V1 and V2
  • [ ] async & blocking negotiation of commits (see push.negotiation)

[erlend-sh]

As he said on Discord, this is apparently one of the key features needed for jujutsu by @martinvonz to seriously consider using gitoxide.

[martinvonz]

Hi, Byron (and others). Jujutsu/jj has come a long way since last time we talked (https://github.com/Byron/gitoxide/discussions/93#discussioncomment-1782772). It's far from just my hobby project and 20% project now. There are several contributors and many users (hard to say how many). Also see our plans for jj at Google from my presentation at Git Merge in September: recording and slides. You could use jj to develop Gitoxide itself :) Feedback welcome, of course.

As @erlend-sh said, and as I said last time, support for push is probably the most important feature we're missing from Gitoxide. I saw that Gitoxide will soon be used in cargo. That's very exciting news! I understand that that's going to be a priority in the near future. I just hope that push support will be a priority soon thereafter. I think it would be beneficial to both projects if jj could switch over to Gitoxide.

[Byron]

Thanks for chiming in, and thanks for posting presentation and slides, I will watch it to get an overview of jj and maybe a better understanding where gitoxide will fit in.

I just hope that push support will be a priority soon thereafter. I think it would be beneficial to both projects if jj could switch over to Gitoxide.

I agree, and would love to make it happen as well. If the Rust Foundation grants pan out, push unfortunately will still not be on the roadmap directly as I will be busy removing git2 from cargo entirely, @pascalkuthe will be speeding up pack creation with server-side tech and maybe provide an MVP of gix upload-pack, while @SidneyDouw will keep driving the oxidization of high-profile projects. The latter could involve push functionality, but it's very unlikely.

That said, I find push missing as well and I will do my best to get it ready somehow, having it would make the client side feel much more complete before and I'd love jj to get even more rusty :D. Let's see what happens.

[hanwen]

async & blocking negotiation of commits

AFAIK push doesn't do negotiation? Server just sends a list of sha1s it has and then its up to the client to omit the things the server already has.

[Byron]

There seems to be a setting for that. When fetching, and when negotiating properly, one is actually independent of what one thinks the server state is in favor what the the server tells us about its state and which objects we actually have (as opposed to what we think we have). Pushes are by default dependent on our last known state of it, but there seem to be cases when this is not good enough or often leads to less than optimal packs.