Sorry to let this issue linger with no comments @thiloschulz. I was coincidentally pretty neck deep in our networking stack, and I was giving this some thought while I was in there. #5286

You mention that libssh2 and WinHTTP both have non-blocking APIs. I think that the bigger problem here is that we've basically plumbed the entirety of our network implementation with blocking assumptions, for better or worse. So I don't think that the problem is underlying support, but what we've done on top of that.

This is certainly possible to unwind, but I think it will be a bit challenging. And finding a way to do it without making a breaking change to the API will be tough as well.

I think that @pks-t has done a little work with a poll function that may help here... #5201

Curious: did you get an opportunity to look at this? If so, I'd love to know what you discovered in your investigation.

I think that the bigger problem here is that we've basically plumbed the entirety of our network implementation with blocking assumptions, for better or worse. So I don't think that the problem is underlying support, but what we've done on top of that.

I am aware of that. Hence this discussion item.

And finding a way to do it without making a breaking change to the API will be tough as well.

On the contrary. It is impossible to get non-blocking semantics from an implementation that is built around blocking I/O, but it is trivial to build a blocking I/O API around a non-blocking one.
As a matter of fact, there need not be any changes to existing API that break compatibility. Maybe to the ABI, yes, as libgit2 internal structures will require a few additional members. But even this appears to be a non-problem to me, as remotes are allocated by git_remote_create*() from within libgit2.

Classically, a user application must implement an event loop (POSIX) or message loop (Windows). libgit2 should provide file descriptors / handles to the application, together with the event type we're expecting, to the user application. Obviosuly, libgit2 must implement a state machine, so that the application can feed received events to libgit2 which then does the right thing depending which stage we're at.
To implement a blocking API, libgit2 uses the non-blocking API internally and uses its own select() call (which I'd recommend for portability reasons) to do what the application would need to do in the non-blocking case. An developer that is content to use the blocking API does not care whether libgit2 blocks in read()/write() or select().

Curious: did you get an opportunity to look at this? If so, I'd love to know what you discovered in your investigation.

Due to the multitude of transports that libgit2 supports, I did not want to put in the effort before I heard from you. If you'd like however, I could try to get the libssh2 backed transport non-blocking and show you the results.

Alright. I believe the API can be made fully backwards-compatible. I have set up a proof of concept here:
#5366
However, user applications need to be recompiled due to changes to the ABI that are required.

If you use another scheme than git_remote_callbacks for telling the user application which events to wait for, such as mandating the user application calls a function like git_remote_get_events() that must be called after GIT_EAGAIN you can even retain full compatibility for the ABI.

The networking stack will require an overhaul, though I suspect it's not as bad as it sounds. For a push or pull operation, there are only a few isolated places, where networking operations actually take place. We just need to split up these functions and keep state between calls.

The whole network stack seems to be a tad messy to me. libgit2 currently offers git_remote_connect() and git_remote_disconnect(). As a naive user, I'd expect I can connect to a server, do as many git_remote_push() or git_remote_pull() operations in between as I want while staying connected, and call git_remote_disconnect() to end the connection. But that's not the case, git_remote_fetch() always disconnects after it has finished. So having these functions be part of the API is kind of pointless.

Also, the ssh transport needs you to specify a GIT_DIRECTION_PUSH / PULL - why not simply open and close ssh channels in the same session, just as is required for the current operation? Are there any other transports that require this direction ugliness?

It would be nice if I one could do away with restrictions like these if such deep reaching changes to the network stack are made.