5 ms·

Git's New Smart HTTP functionality

96 points by schacon 17y ago

timmorgan 17y ago
Awesome stuff. I love how Git just keeps getting better. Funny (to me) aside: "Grack [the Rack-based Git Smart HTTP process] is about half as fast as the Apache version for simple ref-listing stuff, but we’re talking 10ths of a second." When optimizing my web app, reducing request time by 100s of milliseconds (er, I mean, "10ths of a second") would be a monumental occasion. I dance around the room when that happens. Am I wrong in thinking "10ths of a second" might be a dramatic difference for a place like GitHub?
- pmjordan 17y ago
  The user experience of pulling a git repository isn't really comparable to building a website. Also, the effect of a slow web server compounds with each additional resource on the page - as far as I can tell, the added efficiency of the new HTTP code tries to combat exactly that repeated back-and-forth.
- gte910h 17y ago
  I'd suppose they'd just use the apache version then.
- schacon 17y ago
  you have to remember that this is not serving web pages - this is fetching and pushing data, which generally takes several seconds or even minutes. Having a clone take 45 seconds isn't really a big deal, but nobody would wait for a webpage load that long - it's a very different beast. The overhead of a few hundred milliseconds is unnoticeable in almost all cases.
  - timmorgan 17y ago
    Ahh. I see. Thanks for that explanation.
100k 17y ago
Mercurial welcomes git to the HTTP party. ;-)
- vog 17y ago
  I always thought that Mercurial was designed for simplicity and minimalism, while Git was desinged for feature completeness. However, given the very late adoption of HTTP, and the extremely unsatisfactory implementation of "git pull", I wonder whether this is true anymore.
  - dschobel 17y ago
    The most honest technical assessment of the two I've seen yet came from the GoogleCode team when choosing which system to support: http://code.google.com/p/support/wiki/DVCSAnalysis http://code.google.com/p/support/wiki/DVCSAnalysis
    - schacon 17y ago
      that is a pretty seriously flawed report, and was even when it was released almost two years ago. even at the time, nearly everything in both the "Git Advantages" and "Mercurial Advantages" sections are either plain wrong or misunderstood. either ignore the report entirely, or read the comments with point out most of the issues.
      - brodie 17y ago
        Is it? I saw a couple of comments that rightfully pointed out some minor things the analysis ignored like git's reflog and denyNonFastforwards, but it seems reasonable to me beyond that. What other issues are there with the report?
- gwern 17y ago
  And Darcs hopes everyone has been enjoying themselves?
- prog 17y ago
kingkilr 17y ago
Hopefully this means git will be coming to google code! (one of the big reasons they rejected it in favor of hg was that git was so inefficient over http before)
- rquirk 17y ago
  It's not entirely unlikely, there is an issue open that has been reviewed and not rejected: http://code.google.com/p/support/issues/detail?id=2454 http://code.google.com/p/support/issues/detail?id=2454 On a similar issue requesting darcs support (which was closed WontFix), a google engineer wrote: >Supporting Subversion and Mercurial is a lot of effort for our small team. >Adding another version control system is a lot of work and darcs would not be >our first choice. I read that as meaning Git would be next in line, but they are not in any hurry to add it. Personally, I'd rather they concentrated on really making what they do support shine. You can always host the source on git(hub|orious) and add a Sources wiki page that points there.
fragmede 17y ago
Could content-range be used to get similar functionality for downloading without the server-side cgi?
- schacon 17y ago
  That's interesting - I believe it is used to continue partial downloads in dumb http mode. Technically, you can figure out the bytes needed out of the packfile from the index that is downloaded, so I suppose it is possible. However, it would still be way slower than smart-http, because you would have to walk the refs one by one on the client side - one GET, figure out the next object, another GET, etc. With smart-http, you do a short back and forth until the server can figure out the entire list of objects you need and then build a custom packfile for you. And it still wouldn't help push in any way.
zokier 17y ago
This is awesome. Hopefully this also makes Git easier to use on shared hosting, where setting up public git daemon or giving out ssh accounts would be out of question.

96 points by schacon 17y ago

Awesome stuff. I love how Git just keeps getting better. Funny (to me) aside: "Grack [the Rack-based Git Smart HTTP process] is about half as fast as the Apache version for simple ref-listing stuff, but we’re talking 10ths of a second." When optimizing my web app, reducing request time by 100s of milliseconds (er, I mean, "10ths of a second") would be a monumental occasion. I dance around the room when that happens. Am I wrong in thinking "10ths of a second" might be a dramatic difference for a place like GitHub?

pmjordan 17y ago
The user experience of pulling a git repository isn't really comparable to building a website. Also, the effect of a slow web server compounds with each additional resource on the page - as far as I can tell, the added efficiency of the new HTTP code tries to combat exactly that repeated back-and-forth.
gte910h 17y ago
I'd suppose they'd just use the apache version then.
schacon 17y ago
you have to remember that this is not serving web pages - this is fetching and pushing data, which generally takes several seconds or even minutes. Having a clone take 45 seconds isn't really a big deal, but nobody would wait for a webpage load that long - it's a very different beast. The overhead of a few hundred milliseconds is unnoticeable in almost all cases.
- timmorgan 17y ago
  Ahh. I see. Thanks for that explanation.

100k 17y ago

Mercurial welcomes git to the HTTP party. ;-)

vog 17y ago
I always thought that Mercurial was designed for simplicity and minimalism, while Git was desinged for feature completeness. However, given the very late adoption of HTTP, and the extremely unsatisfactory implementation of "git pull", I wonder whether this is true anymore.
- dschobel 17y ago
  The most honest technical assessment of the two I've seen yet came from the GoogleCode team when choosing which system to support: http://code.google.com/p/support/wiki/DVCSAnalysis http://code.google.com/p/support/wiki/DVCSAnalysis
  - schacon 17y ago
    that is a pretty seriously flawed report, and was even when it was released almost two years ago. even at the time, nearly everything in both the "Git Advantages" and "Mercurial Advantages" sections are either plain wrong or misunderstood. either ignore the report entirely, or read the comments with point out most of the issues.
    - brodie 17y ago
      Is it? I saw a couple of comments that rightfully pointed out some minor things the analysis ignored like git's reflog and denyNonFastforwards, but it seems reasonable to me beyond that. What other issues are there with the report?
gwern 17y ago
And Darcs hopes everyone has been enjoying themselves?
prog 17y ago

kingkilr 17y ago

Hopefully this means git will be coming to google code! (one of the big reasons they rejected it in favor of hg was that git was so inefficient over http before)

rquirk 17y ago
It's not entirely unlikely, there is an issue open that has been reviewed and not rejected: http://code.google.com/p/support/issues/detail?id=2454 http://code.google.com/p/support/issues/detail?id=2454 On a similar issue requesting darcs support (which was closed WontFix), a google engineer wrote: >Supporting Subversion and Mercurial is a lot of effort for our small team. >Adding another version control system is a lot of work and darcs would not be >our first choice. I read that as meaning Git would be next in line, but they are not in any hurry to add it. Personally, I'd rather they concentrated on really making what they do support shine. You can always host the source on git(hub|orious) and add a Sources wiki page that points there.

fragmede 17y ago

Could content-range be used to get similar functionality for downloading without the server-side cgi?

schacon 17y ago
That's interesting - I believe it is used to continue partial downloads in dumb http mode. Technically, you can figure out the bytes needed out of the packfile from the index that is downloaded, so I suppose it is possible. However, it would still be way slower than smart-http, because you would have to walk the refs one by one on the client side - one GET, figure out the next object, another GET, etc. With smart-http, you do a short back and forth until the server can figure out the entire list of objects you need and then build a custom packfile for you. And it still wouldn't help push in any way.

zokier 17y ago

This is awesome. Hopefully this also makes Git easier to use on shared hosting, where setting up public git daemon or giving out ssh accounts would be out of question.