Transports and custom data

[alexcrichton]

I've been tackling a few things with custom transports recently, and I've run into a few issues here and there:

• When I call git_transport_register, I hand off my void*, but there doesn't seem to be a point where I get it back? If it is an allocated block it's tough to free it at some point unless I store it personally and free it after a call to git_transport_unregister.

  One concrete instance of this issue is that when using git_smart_subtransport_definition, if it's an allocated block, it's tough to get it back out to deallocate it.

• When using git_smart_subtransport_definition, there's no way to provide custom data to the stored git_smart_subtransport_cb. This is the same as git_transport_register smart subtransport with custom payload #2500, but it seems that it was closed with no resolution?

I would personally be looking for something along the lines of:

• git_transport_unregister takes a *mut *mut c_void parameter (optionally NULL) which receives the data pointer of the unregistered callback.
• git_smart_subtransport_definition gains a free callback like the other git_smart structures.
• git_smart_subtransport_cb also receives the git_smart_subtransport_definition as an argument.

All that being said, I may have missed something!

[alexcrichton]

As a bit of background, I'm exploring connecting curl as an HTTP backend in order to have a solution to #2555 for non-Windows platforms. I was digging through the current src/transports/http.c as I was curious why git_smart_subtransport_cb also received the git_transport, and it looks like the in-tree HTTP takes advantage of the internal transport_smart structure in order to peek at credential and certificate callbacks. If I were to write an alternative HTTP backend, it wouldn't have access to these values, and I'm curious if it's possible to gain access to them?

If I've missed another project where someone's connected libcurl as a backend, I'd be more than willing to use that!

[carlosmn]

The internal structure is just that, a structure we use internally to keep track of data. If you're writing code outside of the library, you'd have your own structure in which you keep data.

The remote will call one of the methods in your object to tell you what the callbacks are. Since it's the same for all libgit2-implemented transports, we use a common function for that, but it doesn't get any special treatment just because it's in the codebase: https://github.com/libgit2/libgit2/blob/master/src/transports/smart.c#L52-L67

[alexcrichton]

Aha yes, that solves that problem, thanks!

[ethomson]

Glad to hear that this was solved. Thanks!