remote: don't free transport on disconnect

[schu]

Currently, git_remote_disconnect not only closes the connection but also
frees the underlying transport object, making it impossible to write
code like

// fetch stuff
git_remote_download()

// close connection
git_remote_disconnect()

// call user provided callback for each ref
git_remote_update_tips(remote, callback)

because remote->refs points to references owned by the transport object.
This means, we have an idling connection while running the callback for
each reference.

Instead, free the transport later with git_remote_free() or on explicit
call of git_remote_free_transport().

cc @carlosmn: Pretty much what we have talked about. Ack?

[travisbot]

This pull request passes (merged 3f3b8ac7 into 52877c8).

[carlosmn]

Yeah, pretty much. Though I don't see why git_remote_free_transport() would be something we'd need or want. Consider this:

// Download all of the things
git_remote_download();
// Open fds are bad
git_remote_disconnect();
// My memory is precious, let's free as much as we can
git_remote_free_transport();
// Now let's update the branches
git_remote_upate_tips(); // OH NOES, segfault!

And we're back to where we started.

[schu]

Yeah, I was undecided. I thought, people might want to reuse the remote object (repeated fetch or something), but that's probably rather uncommon.. Will update.

[vmg]

I'm not seeing this. Why do we need an explicit git_remote_free_transport()? Is there any way to hide that complexity?

[carlosmn]

What we do need is to move freeing the transport to git_remote_free() instead of git_remote_disconect().

git_remote_free_transport() needs to die.

[vmg]

Sounds much more reasonable. Let's do it that way.

[travisbot]

This pull request passes (merged 42ea35c into 52877c8).

[schu]

Done.

[carlosmn]

There we go, 👍