Re: Can I have this, pretty please?
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 12, 2007, 19:29 UTC
- Message-ID
- <854pj4o8k5.fsf@lola.goethe.zz>
- In-Reply-To
- <alpine.LFD.0.999.0708121140190.30176@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 7 quoted lines
> 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.
Not really.
dak@lola:/home/tmp/emacs$ time git-rev-list --parents --topo-order --all>/dev/null
real 0m9.042s user 0m8.801s sys 0m0.168s
This does not even start to _think_ of swapping.
Show 5 quoted lines
> 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.
It does not bother git-rev-list. What takes them time is that they are simply not written with insane amounts of data in mind.
And newsreaders are.
Show 7 quoted lines
> 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.
And newsreaders, for that reason, have a set of strategies for limiting the size of the problem (and changing the limits on the fly as needed) as well as being efficient with handling it. They have to be _good_ at dealing with that amount of data, or they would have fallen by the wayside.
As opposed to gitk and other visualization tools, newsreaders usually have fast and convenient keyboard navigation and an article window where serious amounts of text can be viewed with readable fonts.
If you try selecting a more readable font for gitk, you are limited to selecting between fonts called something starting with the letters "a" to "c" since the font menu runs off the screen after that.
I find that I can't get much use out of gitweb: like webmail, it is simply too little hands-on for getting at the right stuff efficiently: it is all too point and clicky instead direct keyboard access.
So at least for my preferred human-computer interface style, an NNTP-browsable repository would come quite handy. I'll probably fudge something in Gnus (which has the advantage that I _can_ create more direct links to files and trees), but I doubt that the usefulness of the concept would not stretch to actual servers.
-- David Kastrup, Kriemhildstr. 15, 44793 Bochum