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

Re: Why Git is so fast

From
Jakub Narebski <jnareb@gmail.com>
Date
Apr 30, 2009, 19:33 UTC
Message-ID
<200904302134.00569.jnareb@gmail.com>
In-Reply-To
<alpine.LFD.2.00.0904301401120.6741@xanadu.home>
On Thu, 30 Apr 2009, Nicolas Pitre wrote:
> On Thu, 30 Apr 2009, Jakub Narebski wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
Show 15 quoted lines
> > es> Maybe Git is fast because every time they faced one of these "buy
> > es> vs. build" choices, they decided to just write it themselves.
> > 
> > I don't think so.  Rather the opposite is true.  Git uses libcurl for
> > HTTP transport.  Git uses zlib for compression.  Git uses SHA-1 from
> > OpenSSL or from Mozilla.  Git uses (modified, internal) LibXDiff for
> > (binary) deltaifying, for diffs and for merges.
> 
> Well, I think he's right on this point as well.  [...]
> The fact that libxdiff was made internal is indeed to have a better 
> impedance matching with the core code, otherwise it could have remained 
> fully external just like zlib.  And the binary delta code is not 
> libxdiff anymore but a much smaller, straight forward, and optimized to 
> death version to achieve speed over versatility (no need to be versatile 
> when strictly dealing with Git's needs only).

Hrmmmm... I have thought that LibXDiff was internalized mainly for ease of modification, as my impression is that LibXDiff is single developer effort, while Git from beginning have many contributors (and submodules didn't exist then). If I remember correctly the rcsmerge/diff3 algorithm was added first in internalized git's xdiff... was it added to LibXDiff proper, anyway?

BTW. I wonder what other F/OSS version control systems: Bazaar, Mercurial, Darcs, Monotone use for binary deltas, for diff engine, and for textual three-way merge engine. Hmmm... perhaps I'll ask on #revctrl

-- 
Jakub Narebski
Poland
Previous: Andreas Ericsson
Message 39 of 39 in “Eric Sink's blog - notes on git, dscms and a "whole product" approach”
  1. Martin LanghoffApr 27, 2009
  2. Cross-Platform Version Control (was: Eric Sink's blog - notes on git, dscms and a "whole product" approach)Jakub Narebski, Apr 28, 2009
  3. Robin RosenbergApr 28, 2009
  4. Martin LanghoffApr 29, 2009
  5. Jeff KingApr 29, 2009
  6. Markus HeidelbergApr 29, 2009
  7. Jakub NarebskiApr 29, 2009
  8. Martin LanghoffApr 29, 2009
  9. Jakub NarebskiApr 28, 2009
  10. Sitaram ChamartyApr 29, 2009
  11. Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach)Jakub Narebski, Apr 30, 2009
  12. Michael WittenApr 30, 2009
  13. Jakub NarebskiApr 30, 2009
  14. Shawn O. PearceApr 30, 2009
  15. Kjetil BarvikApr 30, 2009
  16. Shawn O. PearceApr 30, 2009
  17. Kjetil BarvikApr 30, 2009
  18. Steven NoonanMay 1, 2009
  19. James PickensMay 1, 2009
  20. Kjetil BarvikMay 1, 2009
  21. Mike HommeyMay 1, 2009
  22. Kjetil BarvikMay 1, 2009
  23. Tony FinchMay 1, 2009
  24. Dmitry PotapovMay 1, 2009
  25. Mike HommeyMay 1, 2009
  26. Dmitry PotapovMay 1, 2009
  27. Shawn O. PearceApr 30, 2009
  28. Jeff KingApr 30, 2009
  29. Linus TorvaldsMay 1, 2009
  30. Jeff KingMay 1, 2009
  31. david@lang.hmMay 1, 2009
  32. Nicolas PitreMay 1, 2009
  33. Daniel BarkalowMay 1, 2009
  34. Linus TorvaldsMay 1, 2009
  35. david@lang.hmMay 1, 2009
  36. Nicolas PitreApr 30, 2009
  37. Alex RiesenApr 30, 2009
  38. Andreas EricssonMay 4, 2009
  39. Jakub NarebskiApr 30, 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.