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

Re: Change set based shallow clone

From
Junio C Hamano <junkio@cox.net>
Date
Sep 10, 2006, 04:54 UTC
Message-ID
<7virjwuxrz.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<e5bfff550609092123t1d8b6c70s5750fbb787534812@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
Show 18 quoted lines
> >>
> >>                     A           <--- tip of branch
> >>                    / \
> >>                   B   E
> >>                   |   |
> >>                   |   F
> >>                   | /
> >>                   C
> >>                   |
> >>                   D
> >>                 ...
> >>
>
> Ok. What about something like this?
> A, B, C, D, E, (-3, 1)F
>
> where -3 is the correct position in sequence and 1 is the number of
> revisions before F to whom apply the -3 rule.

That means F knows who its descendants are, and commit objects do not have that information, so while traversing you need to keep track of all the descendants yourself, doesn't it?

And how does that fix-up information help the user of the stream anyway? If I understand your model correctly, the model does not synchronously draw nodes as they are received, so it keeps track of what it has seen so far. When it sees F it can notice that its parent, C, is something it has seen, so it can tell F is wrong. It also knows that it has seen E and E's parent is F (which turned out to be at a wrong spot), so it can suspect E is also in the wrong spot (now, it is fuzzy to me how that chain of suspicion ends at E and does not propagate up to A, but let's think about that later).

There is one thing that the user knows a lot better than the generic rev-list output part. It is the size of the output window (how tall the window is). I wonder if there is a way to exploit it, either in the user, or telling the size of the window (and perhaps where the display region at the top begins at) to rev-list...

If we are dealing in a 3-item-tall window, we will traverse A B C D, notice they form a single strand of pearls, and can make a mental note that we do not have to worry about ancestors of D for now, because D's ancestors will be drawn below C, which is already the putative bottom edge of the window (when oddballs like E and F comes later, they can only push things down at the bottom edge of the window). Then rev-list can postpone traversing D and go on to traverse other nodes that are in the "active" list (in this case, E).

I am starting to suspect that introducing "generation" header to the commit objects might actually be a very good thing. For one thing, rev-list will automatically get the topology always right if we did so.

We obviously need to update 'convert-objects' and tell everybody that they need to rewrite their history if we take this route. That kind of flag-day conversion used to be an Ok thing to do, but it is getting harder and harder these days for obvious reasons, though.

Previous: Marco CostalbaNext: Marco Costalba
Message 91 of 99 in “Change set based shallow clone”
  1. Jon SmirlSep 7, 2006
  2. Jakub NarebskiSep 7, 2006
  3. Jon SmirlSep 7, 2006
  4. Jeff KingSep 7, 2006
  5. Jakub NarebskiSep 7, 2006
  6. Jakub NarebskiSep 7, 2006
  7. Junio C HamanoSep 7, 2006
  8. Jon SmirlSep 7, 2006
  9. Anand KumriaSep 10, 2006
  10. Andreas EricssonSep 8, 2006
  11. Junio C HamanoSep 7, 2006
  12. Jakub NarebskiSep 7, 2006
  13. Martin LanghoffSep 8, 2006
  14. Junio C HamanoSep 8, 2006
  15. Martin LanghoffSep 8, 2006
  16. Junio C HamanoSep 8, 2006
  17. A Large Angry SCMSep 8, 2006
  18. Jon SmirlSep 8, 2006
  19. Jakub NarebskiSep 8, 2006
  20. Petr BaudisSep 9, 2006
  21. Jakub NarebskiSep 9, 2006
  22. Aneesh Kumar K.VSep 8, 2006
  23. linux@horizon.comSep 8, 2006
  24. Jon SmirlSep 8, 2006
  25. Jakub NarebskiSep 8, 2006
  26. Junio C HamanoSep 8, 2006
  27. linux@horizon.comSep 8, 2006
  28. Jon SmirlSep 8, 2006
  29. Jakub NarebskiSep 8, 2006
  30. Linus TorvaldsSep 8, 2006
  31. Jon SmirlSep 8, 2006
  32. Paul MackerrasSep 8, 2006
  33. Jon SmirlSep 9, 2006
  34. Paul MackerrasSep 10, 2006
  35. Jon SmirlSep 10, 2006
  36. linux@horizon.comSep 10, 2006
  37. Jon SmirlSep 10, 2006
  38. linux@horizon.comSep 10, 2006
  39. Linus TorvaldsSep 10, 2006
  40. Jon SmirlSep 10, 2006
  41. Linus TorvaldsSep 11, 2006
  42. Paul MackerrasSep 10, 2006
  43. Linus TorvaldsSep 11, 2006
  44. Linus TorvaldsSep 11, 2006
  45. Junio C HamanoSep 11, 2006
  46. Junio C HamanoSep 11, 2006
  47. Paul MackerrasSep 11, 2006
  48. linux@horizon.comSep 11, 2006
  49. Jon SmirlSep 11, 2006
  50. Junio C HamanoSep 11, 2006
  51. Paul MackerrasSep 11, 2006
  52. Junio C HamanoSep 11, 2006
  53. Jakub NarebskiSep 12, 2006
  54. Junio C HamanoSep 12, 2006
  55. Jakub NarebskiSep 12, 2006
  56. Jakub NarebskiSep 11, 2006
  57. Junio C HamanoSep 10, 2006
  58. Shawn PearceSep 11, 2006
  59. Junio C HamanoSep 11, 2006
  60. Shawn PearceSep 11, 2006
  61. Junio C HamanoSep 11, 2006
  62. Jakub NarebskiSep 11, 2006
  63. Shawn PearceSep 11, 2006
  64. Junio C HamanoSep 11, 2006
  65. Shawn PearceSep 11, 2006
  66. Junio C HamanoSep 11, 2006
  67. Shawn PearceSep 11, 2006
  68. Jon SmirlSep 11, 2006
  69. Paul MackerrasSep 9, 2006
  70. Linus TorvaldsSep 9, 2006
  71. Junio C HamanoSep 9, 2006
  72. Paul MackerrasSep 9, 2006
  73. Linus TorvaldsSep 9, 2006
  74. Marco CostalbaSep 9, 2006
  75. Linus TorvaldsSep 9, 2006
  76. Marco CostalbaSep 9, 2006
  77. linux@horizon.comSep 9, 2006
  78. Marco CostalbaSep 9, 2006
  79. Linus TorvaldsSep 9, 2006
  80. Jeff KingSep 9, 2006
  81. Junio C HamanoSep 9, 2006
  82. Jeff KingSep 9, 2006
  83. Linus TorvaldsSep 9, 2006
  84. Jon SmirlSep 9, 2006
  85. Linus TorvaldsSep 10, 2006
  86. Junio C HamanoSep 10, 2006
  87. Marco CostalbaSep 10, 2006
  88. Junio C HamanoSep 10, 2006
  89. Marco CostalbaSep 10, 2006
  90. Marco CostalbaSep 10, 2006
  91. Junio C HamanoSep 10, 2006
  92. Marco CostalbaSep 10, 2006
  93. Junio C HamanoSep 10, 2006
  94. linux@horizon.comSep 10, 2006
  95. Marco CostalbaSep 10, 2006
  96. Paul MackerrasSep 11, 2006
  97. linux@horizon.comSep 11, 2006
  98. Jakub NarebskiSep 10, 2006
  99. Josef WeidendorferSep 10, 2006

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.