Re: [PATCH 5/5] Remove unnecessary 'fetch' argument from transport_get API

["Shawn O. Pearce" <spearce@spearce.org>]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> We don't actually need to know at the time of transport_get if the
> caller wants to fetch, push, or do both on the returned object.
> It is easier to just delay the initialization of the HTTP walker
> until we know we will need it by providing a CURL specific fetch
> function in the curl_transport that makes sure the walker instance
> is initialized before use.

Daniel privately emailed me his rationale for why this fetch argument
was here in the first place and I mostly agree with him, but will
be working up a more clear API replacement in the near future.
The "1/0","fetch/push" thing is not the clearest way that we could
define the API.

Right now this patch is required to go along with my 1/5 bug fix,
as without this patch we get the sequence:

	http_init()
	http_init()
	... use http ...
	http_cleanup()
	... try to use http again and barf ...

This 5/5 makes the sequence be in proper order by delaying creation
of the HTTP walker object (and thus one of the http_init() calls)
to after the first http_cleanup(), so we get the nice neat order of:

	http_init()
	... use http ...
	http_cleanup()
	http_init()
	... use http just fine ...
	http_cleanup()

I'll be honest here; I did not test 1/5 or 5/5 on their own.
I only tested the combined result of them, and that creates a
working HTTP fetch.  But I'm pretty sure that one of these patches
alone will still cause SIGSEGV/SIGBUS errors during HTTP fetch due
to either the bad cleanup (1/5 fixes) or the bad init ordering I'm
talking about above (5/5 fixes).

Reinstating a replacement for the fetch parameter that I removed
in this patch isn't critical for functionality, but will be
necessary to do performance optimization in the form of reusing
the connection between ref discovery and pack transfer in the
native protocol.  Right now I'm focusing on making builtin-fetch
stable and implementing prior behavior.  Once its solid enough to
graduate to `next` we can start doing some of the optimization work.
 
-- 
Shawn.