When a cache miss occurs, the server will first completely stream the clone pack to the cache before streaming any data to the remote client. The result is that on a cache miss, you get nothing for some time and then suddenly the 'Counting objects' feedback flies from 0 to 100%.

The user experience would be better if while the pack is being written to the cache, the first part of the pack would already be streamed to the client.

Things to consider:

• We don't want to spin up another thread on every cache miss.
• We don't want to multiplex to the cache and the client at a fixed rate. This would slow down the overall process to the lowest common denominator.

Ideally, we'd have a single cache-miss-streamer thread that slowly streams parts of the cache-entry to the client while it is still being written. It's fine if that happens at a slower rate then the client can process.

When the cache write completes, the main thread should take over again and stream the remainder of the cache entry.