-
Notifications
You must be signed in to change notification settings - Fork 2.5k
add callback before a remote connects and add a callback before a remote will be disconnected #6298
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 8000 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
TODO: Maybe it is possible to just define the disconnect and the remote_ready_cb can be used instead of the connect |
Why git_remote_ready_cb remote_ready; is not defined as GIT_CALLBACK()? |
It is - Line 538 in 258df9c
|
Ah I haven't seen this thanks. Is this the way it should be added to the struct? So I will change it for my callbacks too |
Current error in the tests: "remote error: TODO: use a different repo, because fetching libgit2 takes quite long. @ethomson which repo do you propose? |
8850fa7
to
5c6f2ba
Compare
…ote will be disconnected # Conflicts: # tests/libgit2/online/fetch.c
…ccess to github over port 9418 is anymore supported
5c6f2ba
to
217dbc8
Compare
Problem Description:
When updating submodules, the remote of the submodule is not visible outside of the submodule (submodule is a private type and therefore not intended to be used outside). So in that case it is not possible to abort an update operation by aborting the remote connection.
Benefit:
If during the submodule update (fetch, ...) a callback will be called, outside of the submodule the remote is available. This remote can be stored and if the application wants to abort the operation it just stops the operation on that remote.
from #5730
In this particular case, I added the connect/disconnect callbacks because I needed to remember the remote to cancel the transfer later on. This is most important in submodule update, which looks up the remotes internally. Without this, there isn't a way to cancel the transfers initiated by submodule update.