While this will rarely be different from the default, having it in the remote adds yet another setting it has to keep around and can affect its behaviour. Move it to the options.
Instead of having it set in a different place from every other callback, put it the main structure. This removes some state from the remote and makes it behave more like clone, where the constructors are passed via the options.
Having the setting be different from calling its actions was not a great idea and made for the sake of the wrong convenience. Instead of that, accept either fetch options, push options or the callbacks when dealing with the remote. The fetch options are currently only the callbacks, but more options will be moved from setters and getters on the remote to the options. This does mean passing the same struct along the different functions but the typical use-case will only call git_remote_fetch() or git_remote_push() and so won't notice much difference.
Remote-tracking branch prunning
Instead we provide git_remote_upload() and git_remote_update_tips() in order to have a parallel API for fetching and pushing.
When a list of refspecs is passed to fetch (what git would consider refspec passed on the command-line), we not only need to perform the updates described in that refspec, but also update the remote-tracking branch of the fetched remote heads according to the remote's configured refspecs. These "fetches" are not however to be written to FETCH_HEAD as they would be duplicate data, and it's not what the user asked for.
The configured/base fetch refspecs need to be taken into account in order to implement opportunistic remote-tracking branch updates. DWIM them and store them in the struct, but don't do anything with them yet.
This option make it easy to ignore anything about the server we're connecting to, which is bad security practice. This was necessary as we didn't use to expose detailed information about the certificate, but now that we do, we should get rid of this. If the user wants to ignore everything, they can still provide a callback which ignores all the information passed.
* Move the transport registration mechanisms into a new header under 'sys/' because this is advanced stuff. * Remove the 'priority' argument from the registration as it adds unnecessary complexity. (Since transports cannot decline to operate, only the highest priority transport is ever executed.) Users who require per-priority transports can implement that in their custom transport themselves. * Simplify registration further by taking a scheme (eg "http") instead of a prefix (eg "http://").