Jeff King <peff@xxxxxxxx> writes: > Clients do not have to _just_ fetch a packfile. They could get a bundle > file that contains the roots along with the packfile. I know that one of > your goals is not duplicating the storage of the packfile on the server, > but it would not be hard for the server to store the packfile and the > bundle header separately, and concatenate them on the fly. Yeah, I was wondering about that. Just storing them as separate two-file pair on the server side and serving it as if it is a single file to the client does not sound like a rocket science, and a reasonable webserver should be able to serve even a byte-range request out of such a thing. Of course, updating the clients to understand such a two-file pair as a valid bundle is a good thing to do, and I like that step 0. you outlined below. > 0. During gc, server generates pack-1234abcd.pack. It writes matching > tips into pack-1234abcd.info, which is essentially a bundle file > whose final line says "pack-1234abcd.pack". > > 1. Client contacts server via any git protocol. Server says > "resumable=<url>". Let's says that <url> is > https://example.com/repo/clones/1234abcd.bundle. > > 2. Client goes to <url>. They see that they are fetching a bundle, > and know not to do the usual smart-http or dumb-http protocols. > They can fetch the bundle header resumably (though it's tiny, so it > doesn't really matter). > ... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html