On Thu, Mar 3, 2016 at 9:57 AM, Junio C Hamano <gits...@pobox.com> wrote: > Duy Nguyen <pclo...@gmail.com> writes: > >> would it be >> ok if we introduced a minimal resumable download service via >> git-daemon to enable this feature with very little setup? Like >> git-shell, you can only download certain packfiles for this use case >> and nothing else with this service. > > I think it is a matter of priorities. > > A minimalistic site that offers only git-daemon traffic without a > working HTTP server would certainly benefit from such a thing, but > serving static files efficiently over the web is commodity service > these days. Wouldn't it be sufficient to just recommend having a > normal HTTP server serving static files, which should be "very > little setup" in today's world? > > Such a "minimal resumable download service" over the git-daemon > transport still has to reinvent what is already done well by the > HTTP servers and clients (e.g. support of ETag equivalent to make > sure that the client can notice that the underlying data has changed > for a given resource, headers to communicate the total length, > making a range request and responding to it, etc. etc.). > > In addition,, by going the custom protocol route, you wouldn't > benefit from caching HTTP proxies available to the clients. > > So I am not sure if the benefit outweighs the cost.
What I had in mind was individuals who just want to publish their work over git://. Right now it's just a matter of running git-daemon and configuring it a bit. If it was me, I wouldn't expect all the bells and whistles that come with http. But I agree that this is low priority, "scratch your own itch" kind of thing. Let's have resumable clone with standard download protocols first, then we'll see. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
