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

Re: Can I have this, pretty please?

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Aug 12, 2007, 18:48 UTC
Message-ID
<alpine.LFD.0.999.0708121140190.30176@woody.linux-foundation.org>
In-Reply-To
<alpine.LFD.0.999.0708121135050.30176@woody.linux-foundation.org>
On Sun, 12 Aug 2007, Linus Torvalds wrote:
> 
> A newsreader is mis-designed for all the same reasons SVN is misdesigned: 
> it sees the messages (commits) as a _tree_.

Side note: the lack of this bug is what makes showing large histories graphically be expensive in the first place.

In fact, in git, merges are "first-class" entities, and forking is something you have to infer from the history (by finding two commits with the same parent), and that's why calculating the graph is actually pretty expensive: when you do so, you have to keep all the commit relationships in memory, and you basically have to sort it topologically.

So even if you don't want to show the graph itself (and just add references to allow the user to walk to parents/children manually), you'd still have to calculate - and keep track of - the commit relationships. And I suspect that's what makes gitk and other visualizers take time.

I think one solution is to limit the size fo the visualization by date or number, ie if you want to see history, it's often useful to do things like

	gitk --since=10.weeks.ago

to see just the "recent" commits. That very fundamentally makes the problem much cheaper, because you simply have to generate the graph for a much smaller set of commits.

I used to think that we should just default to some reasonable value, but then we optimized the hell out of git-rev-list and Paul fixed a number of scalability issues in gitk too, so it kind of fell by the wayside because it wasn't as important any more. But if you have a huge project with lots of history, the right answer may well be to make gitk *default* to using something like "show only the last year unless some revision limiting has been done explicitly".

IOW, showing the whole history for a big project is simply pretty expensive. If you have a hundred thousand commits, just keeping track of the tree structure *is* going to take megabytes and megabytes of data. Limiting the size of the problem is usually a really good solution, especially since most people tend to care about what happened in the last few days, not what happened five months ago.

			Linus
Previous: Linus TorvaldsNext: Jon Smirl
Message 5 of 29 in “Can I have this, pretty please?”
  1. David KastrupAug 12, 2007
  2. Steven GrimmAug 12, 2007
  3. David KastrupAug 12, 2007
  4. Linus TorvaldsAug 12, 2007
  5. Linus TorvaldsAug 12, 2007
  6. Jon SmirlAug 12, 2007
  7. Linus TorvaldsAug 12, 2007
  8. David KastrupAug 12, 2007
  9. David KastrupAug 12, 2007
  10. Uwe Kleine-KönigAug 12, 2007
  11. David KastrupAug 12, 2007
  12. Linus TorvaldsAug 12, 2007
  13. Linus TorvaldsAug 12, 2007
  14. David KastrupAug 12, 2007
  15. Paul MackerrasAug 13, 2007
  16. David KastrupAug 13, 2007
  17. David KastrupAug 12, 2007
  18. Linus TorvaldsAug 12, 2007
  19. David KastrupAug 12, 2007
  20. Linus TorvaldsAug 12, 2007
  21. David KastrupAug 12, 2007
  22. Govind SalinasAug 12, 2007
  23. David KastrupAug 12, 2007
  24. Martin LanghoffAug 12, 2007
  25. David KastrupAug 12, 2007
  26. Jeff KingAug 12, 2007
  27. Jeff KingAug 12, 2007
  28. David KastrupAug 12, 2007
  29. Jeff KingAug 12, 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.