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

Re: Smart fetch via HTTP?

From
A Large Angry SCM <gitzilla@gmail.com>
Date
May 15, 2007, 22:30 UTC
Message-ID
<464A3471.9070007@gmail.com>
In-Reply-To
<20070515201006.GD3653@efreet.light.src>
Jan Hudec wrote:
Show 31 quoted lines
> Hello,
> 
> Did anyone already think about fetching over HTTP working similarly to the
> native git protocol?
> 
> That is rather than reading the raw content of the repository, there would be
> a CGI script (could be integrated to gitweb), that would negotiate what the
> client needs and then generate and send a single pack with it.
> 
> Mercurial and bzr both have this option. It would IMO have three benefits:
>  - Fast access for people behind paranoid firewalls, that only let http and
>    https (you can tunel anything through, but only to port 443) through.
>  - Can be run on shared machine. If you have web space on machine shared
>    by many people, you can set up your own gitweb, but cannot/are not allowed
>    to start your own network server for git native protocol.
>  - Less things to set up. If you are setting up gitweb anyway, you'd not need
>    to set up additional thing for providing fetch access.
> 
> Than a question is how to implement it. The current protocol is stateful on
> both sides, but the stateless nature of HTTP more or less requires the
> protocol to be stateless on the server.
> 
> I think it would be possible to use basically the same protocol as now, but
> make it stateless for server. That is server first sends it's heads and than
> client repeatedly sends all it's wants and some haves until the server acks
> all of them and sends the pack.
> 
> Alternatively I am thinking about using Bloom filters (somebody came with
> such idea on the bzr list when I still followed it). It might be useful, as
> over HTTP we need to send as many haves as possible in one go.
> 
Bundles?

Client POSTs it's ref set; server uses the ref set to generate and return the bundle.

Push over http(s) could work the same...
Previous: Jan HudecNext: Shawn O. Pearce
Message 2 of 47 in “Smart fetch via HTTP?”
  1. Jan HudecMay 15, 2007
  2. A Large Angry SCMMay 15, 2007
  3. Shawn O. PearceMay 15, 2007
  4. Junio C HamanoMay 16, 2007
  5. Martin LanghoffMay 16, 2007
  6. Johannes SchindelinMay 16, 2007
  7. Martin LanghoffMay 16, 2007
  8. Jakub NarebskiMay 16, 2007
  9. Johannes SchindelinMay 17, 2007
  10. Shawn O. PearceMay 17, 2007
  11. david@lang.hmMay 17, 2007
  12. Shawn O. PearceMay 17, 2007
  13. Shawn O. PearceMay 17, 2007
  14. Theodore TsoMay 17, 2007
  15. Nicolas PitreMay 17, 2007
  16. Johannes SchindelinMay 17, 2007
  17. Nicolas PitreMay 17, 2007
  18. Martin LanghoffMay 17, 2007
  19. Nicolas PitreMay 17, 2007
  20. Jan HudecMay 17, 2007
  21. Nicolas PitreMay 17, 2007
  22. david@lang.hmMay 17, 2007
  23. Johannes SchindelinMay 18, 2007
  24. Jan HudecMay 18, 2007
  25. Matthieu MoyMay 17, 2007
  26. Martin LanghoffMay 17, 2007
  27. Johannes SchindelinMay 17, 2007
  28. Matthieu MoyMay 17, 2007
  29. Martin LanghoffMay 17, 2007
  30. Nicolas PitreMay 17, 2007
  31. Jakub NarebskiMay 17, 2007
  32. Nicolas PitreMay 17, 2007
  33. Petr BaudisMay 17, 2007
  34. Matthieu MoyMay 17, 2007
  35. Linus TorvaldsMay 18, 2007
  36. alanMay 18, 2007
  37. Joel BeckerMay 18, 2007
  38. Matthieu MoyMay 18, 2007
  39. Linus TorvaldsMay 18, 2007
  40. Joel BeckerMay 18, 2007
  41. Jan HudecMay 20, 2007
  42. david@lang.hmMay 19, 2007
  43. Shawn O. PearceMay 19, 2007
  44. david@lang.hmMay 19, 2007
  45. Jan HudecMay 17, 2007
  46. Nicolas PitreMay 17, 2007
  47. Jan HudecMay 18, 2007

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.