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

Re: Git and GCC

From
Jakub Narebski <jnareb@gmail.com>
Date
Dec 7, 2007, 00:29 UTC
Message-ID
<m3y7c7tkbs.fsf@roke.D-201>
In-Reply-To
<alpine.LFD.0.9999.0712061118050.13796@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 6 Dec 2007, Jon Loeliger wrote:
Show 25 quoted lines
>> I guess one question I posit is, would it be more accurate
>> to think of this as a "delta net" in a weighted graph rather
>> than a "delta chain"?
> 
> It's certainly not a simple chain, it's more of a set of acyclic directed 
> graphs in the object list. And yes, it's weigted by the size of the delta 
> between objects, and the optimization problem is kind of akin to finding 
> the smallest spanning tree (well, forest - since you do *not* want to 
> create one large graph, you also want to make the individual trees shallow 
> enough that you don't have excessive delta depth).
> 
> There are good algorithms for finding minimum spanning trees, but this one 
> is complicated by the fact that the biggest cost (by far!) is the 
> calculation of the weights itself. So rather than really worry about 
> finding the minimal tree/forest, the code needs to worry about not having 
> to even calculate all the weights!
> 
> (That, btw, is a common theme. A lot of git is about traversing graphs, 
> like the revision graph. And most of the trivial graph problems all assume 
> that you have the whole graph, but since the "whole graph" is the whole 
> history of the repository, those algorithms are totally worthless, since 
> they are fundamentally much too expensive - if we have to generate the 
> whole history, we're already screwed for a big project. So things like 
> revision graph calculation, the main performance issue is to avoid having 
> to even *look* at parts of the graph that we don't need to see!)
Hmmm...

I think that these two problems (find minimal spanning forest with limited depth and traverse graph) with the additional constraint to avoid calculating weights / avoid calculating whole graph would be a good problem to present at CompSci course.

Just a thought...
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Previous: Linus TorvaldsNext: Junio C Hamano
Message 75 of 89 in “Re: Git and GCC”
  1. David MillerDec 6, 2007
  2. Daniel BerlinDec 6, 2007
  3. David MillerDec 6, 2007
  4. Daniel BerlinDec 6, 2007
  5. David MillerDec 6, 2007
  6. Harvey HarrisonDec 6, 2007
  7. Daniel BerlinDec 6, 2007
  8. David MillerDec 6, 2007
  9. Daniel BerlinDec 6, 2007
  10. Harvey HarrisonDec 6, 2007
  11. Daniel BerlinDec 6, 2007
  12. Jon SmirlDec 6, 2007
  13. Jeff KingDec 6, 2007
  14. Nicolas PitreDec 6, 2007
  15. Jeff KingDec 6, 2007
  16. Nicolas PitreDec 6, 2007
  17. Jeff KingDec 7, 2007
  18. Jeff KingDec 7, 2007
  19. Linus TorvaldsDec 6, 2007
  20. Jon SmirlDec 6, 2007
  21. Nicolas PitreDec 6, 2007
  22. Jon SmirlDec 6, 2007
  23. Nicolas PitreDec 6, 2007
  24. Jon SmirlDec 6, 2007
  25. Jon SmirlDec 6, 2007
  26. Nicolas PitreDec 6, 2007
  27. Jon SmirlDec 6, 2007
  28. Jeff KingDec 7, 2007
  29. Harvey HarrisonDec 8, 2007
  30. Gabriel PaubertDec 10, 2007
  31. Nicolas PitreDec 10, 2007
  32. David MillerDec 7, 2007
  33. Jeff KingDec 7, 2007
  34. Jon SmirlDec 7, 2007
  35. David MillerDec 7, 2007
  36. Linus TorvaldsDec 7, 2007
  37. Giovanni BajoDec 7, 2007
  38. Jakub NarebskiDec 7, 2007
  39. Luke LuDec 7, 2007
  40. Giovanni BajoDec 7, 2007
  41. Daniel BerlinDec 7, 2007
  42. Johannes SchindelinDec 8, 2007
  43. David MillerDec 8, 2007
  44. David MillerDec 10, 2007
  45. Linus TorvaldsDec 6, 2007
  46. Harvey HarrisonDec 6, 2007
  47. David BrownDec 6, 2007
  48. Nicolas PitreDec 6, 2007
  49. gc --aggressive: make it really aggressiveJohannes Schindelin, Dec 6, 2007
  50. Theodore TsoDec 6, 2007
  51. Nicolas PitreDec 6, 2007
  52. Pierre HabouzitDec 6, 2007
  53. Johannes SchindelinDec 6, 2007
  54. David KastrupDec 6, 2007
  55. Harvey HarrisonDec 6, 2007
  56. Johannes SchindelinDec 6, 2007
  57. Linus TorvaldsDec 6, 2007
  58. Johannes SchindelinMar 18, 2009
  59. Teemu LikonenMar 18, 2009
  60. Nicolas PitreMar 18, 2009
  61. Daniel BerlinDec 6, 2007
  62. Linus TorvaldsDec 6, 2007
  63. Harvey HarrisonDec 7, 2007
  64. Linus TorvaldsDec 7, 2007
  65. Jon SmirlDec 7, 2007
  66. Nicolas PitreDec 7, 2007
  67. Linus TorvaldsDec 7, 2007
  68. Jon SmirlDec 7, 2007
  69. Nicolas PitreDec 7, 2007
  70. NightStrikeDec 6, 2007
  71. Linus TorvaldsDec 6, 2007
  72. NightStrikeDec 7, 2007
  73. Jon LoeligerDec 6, 2007
  74. Linus TorvaldsDec 6, 2007
  75. Jakub NarebskiDec 7, 2007
  76. Junio C HamanoDec 6, 2007
  77. Junio C HamanoDec 6, 2007
  78. David KastrupDec 6, 2007
  79. [OT] Re: Git and GCCRandy Dunlap, Dec 6, 2007
  80. Harvey HarrisonDec 6, 2007
  81. Linus TorvaldsDec 6, 2007
  82. Harvey HarrisonDec 6, 2007
  83. Johannes SchindelinDec 6, 2007
  84. Ismail DönmezDec 6, 2007
  85. "Argument list too long" in git remote update (Was: Git and GCC)Geert Bosch, Dec 17, 2007
  86. Johannes SchindelinDec 17, 2007
  87. Linus TorvaldsDec 17, 2007
  88. Derek FawcusDec 18, 2007
  89. Shawn O. PearceDec 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.