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

Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 2, 2009, 18:41 UTC
Message-ID
<7vk4x5fcbf.fsf@alter.siamese.dyndns.org>
In-Reply-To
<fabb9a1e0912021006x2905578bo16dbcaedc0d97bc6@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
Show 5 quoted lines
>> Of course, I never understood why the backend should know the
>> implementation detail that it is based on cURL, so it would be even more
>> modular (at least by my definition) if there was no hard-coded mapping.
>
> Agreed.
I don't get this point at all.

Backend is _very_ aware of how it is implemented itself. Naming one implementation git-remote-http is to declare that "I am the one and only implementation of http handler" and forces another implementation of http handler, perhaps based on different toolkit than libcurl, to forever be a second class citizen that need to use name other than 'http'.

The "mapping" you two are calling "hard-coded" may be "hard-coded" but is a better kind of hard-coding than hard-coding "http" to "this particular implementation" implicitly like you two seem to be advocating. Think of it as having one extra layer of indirection.

When the second implementation of http handler proves to be better than the current one, we can flip the mapping, and anybody who were using "http://" to access some repository will automatically updated to use the new backend instead of the old one. With your scheme, you probably could change the name of the old "http" backend to "http-deprecated" and the new one from "second-class-citizen-http" to "http" to achieve a similar effect, but I do not think it is as nice as having one extra level of indirection.

> However, I am not convinced that we should do any magic to map
> "foo://" to git-remote-foo. On the other hand, I do think it makes
> sense to have something modular that allows "git-remote-http" to be
> implemented as a separate package that can be installed.

As I said, I do think modular is good, but I think what Dscho is advocating does not have much to achieve that goal.

Previous: Sverre RabbelierNext: Sverre Rabbelier
Message 32 of 42 in “Git remote helpers to implement smart transports.”
  1. 0/8 Git remote helpers to implement smart transports.Ilari Liusvaara, Dec 1, 2009
  2. 1/8 Pass unknown protocols to external protocol handlersIlari Liusvaara, Dec 1, 2009
  3. 2/8 Refactor git transport options parsingIlari Liusvaara, Dec 1, 2009
  4. 3/8 Support taking over transportsIlari Liusvaara, Dec 1, 2009
  5. 4/8 Support remote helpers implementing smart transportsIlari Liusvaara, Dec 1, 2009
  6. Shawn O. PearceDec 1, 2009
  7. Ilari LiusvaaraDec 2, 2009
  8. Shawn O. PearceDec 2, 2009
  9. Ilari LiusvaaraDec 2, 2009
  10. Shawn O. PearceDec 3, 2009
  11. Shawn O. PearceDec 2, 2009
  12. 5/8 Support remote archive from external protocol helpersIlari Liusvaara, Dec 1, 2009
  13. 6/8 Remove special casing of http, https and ftpIlari Liusvaara, Dec 1, 2009
  14. Shawn O. PearceDec 1, 2009
  15. Ilari LiusvaaraDec 1, 2009
  16. Daniel BarkalowDec 1, 2009
  17. Ilari LiusvaaraDec 2, 2009
  18. 7/8 Add remote helper debug modeIlari Liusvaara, Dec 1, 2009
  19. 8/8 Support mandatory capabilitiesIlari Liusvaara, Dec 1, 2009
  20. Sverre RabbelierDec 1, 2009
  21. Shawn O. PearceDec 1, 2009
  22. Ilari LiusvaaraDec 1, 2009
  23. Shawn O. PearceDec 1, 2009
  24. Junio C HamanoDec 1, 2009
  25. Shawn O. PearceDec 1, 2009
  26. Ilari LiusvaaraDec 2, 2009
  27. Junio C HamanoDec 2, 2009
  28. Ilari LiusvaaraDec 2, 2009
  29. Junio C HamanoDec 2, 2009
  30. Johannes SchindelinDec 2, 2009
  31. Sverre RabbelierDec 2, 2009
  32. Junio C HamanoDec 2, 2009
  33. Sverre RabbelierDec 2, 2009
  34. Junio C HamanoDec 2, 2009
  35. Sverre RabbelierDec 2, 2009
  36. Junio C HamanoDec 2, 2009
  37. Jeff KingDec 2, 2009
  38. Ilari LiusvaaraDec 2, 2009
  39. Junio C HamanoDec 2, 2009
  40. Ilari LiusvaaraDec 2, 2009
  41. Ilari LiusvaaraDec 2, 2009
  42. Ilari LiusvaaraDec 2, 2009

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.