git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 4/4] bundle v3: the beginning

From
Duy Nguyen <pclouds@gmail.com>
Date
Mar 3, 2016, 05:15 UTC
Message-ID
<CACsJy8BONz-q7kW4zsOyq4O+YJOmDoNF1tjp5-kDBbPnx7mC-w@mail.gmail.com>
In-Reply-To
<xmqqwppk2rqo.fsf@gitster.mtv.corp.google.com>
On Thu, Mar 3, 2016 at 9:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 28 quoted lines
> Duy Nguyen <pclouds@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
Previous: Junio C HamanoNext: Christian Couder
Message 13 of 37 in “bundle: plug resource leak”
  1. 1/2 bundle: plug resource leakJunio C Hamano, Mar 1, 2016
  2. 2/2 bundle: keep a copy of bundle file name in the in-core bundle headerJunio C Hamano, Mar 1, 2016
  3. Jeff KingMar 2, 2016
  4. Junio C HamanoMar 2, 2016
  5. 0/4 "split bundle" previewJunio C Hamano, Mar 2, 2016
  6. 1/4 bundle doc: 'verify' is not about verifying the bundleJunio C Hamano, Mar 2, 2016
  7. 2/4 bundle: plug resource leakJunio C Hamano, Mar 2, 2016
  8. 3/4 bundle: keep a copy of bundle file name in the in-core bundle headerJunio C Hamano, Mar 2, 2016
  9. Jeff KingMar 2, 2016
  10. 4/4 bundle v3: the beginningJunio C Hamano, Mar 2, 2016
  11. Duy NguyenMar 3, 2016
  12. Junio C HamanoMar 3, 2016
  13. Duy NguyenMar 3, 2016
  14. Christian CouderMay 20, 2016
  15. Duy NguyenMay 31, 2016
  16. Christian CouderMay 31, 2016
  17. Duy NguyenJun 1, 2016
  18. Christian CouderJun 7, 2016
  19. Duy NguyenJun 1, 2016
  20. Christian CouderJun 7, 2016
  21. Mike HommeyJun 7, 2016
  22. Duy NguyenJun 7, 2016
  23. Junio C HamanoJun 7, 2016
  24. Jeff KingJun 7, 2016
  25. Duy NguyenJun 8, 2016
  26. Jeff KingJun 8, 2016
  27. Duy NguyenJun 9, 2016
  28. Jeff KingJun 9, 2016
  29. Junio C HamanoJun 8, 2016
  30. Jeff KingJun 8, 2016
  31. Jeff KingMay 31, 2016
  32. Jeff KingMay 31, 2016
  33. Christian CouderJun 7, 2016
  34. Jeff KingJun 7, 2016
  35. Jeff KingMar 2, 2016
  36. Junio C HamanoMar 2, 2016
  37. Jeff KingMar 2, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.