Re: Can I have this, pretty please?
- From
David Kastrup <dak@gnu.org>
- Date
- Aug 12, 2007, 19:46 UTC
- Message-ID
- <85wsw0mt77.fsf@lola.goethe.zz>
- In-Reply-To
- <alpine.LFD.0.999.0708121219540.30176@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 9 quoted lines
> On Sun, 12 Aug 2007, David Kastrup wrote: >> >> > But to visualize a history, it's useless. >> >> Not half as useless as existing git-specific tools. They thrash my >> computer to death on serious sized trees. > > So, use "git log --pretty=oneline" instead, which doesn't have the > expense.
Yes, like managing a manual with grep is all one needs. git log --pretty=oneline provides just the commit headers, but offers no way to jump into the commits themselves and back easily.
> I don't see why you think that using nntp would help anything. The > _problem_ is still the same one, of calculating full > reachability. It didn't go away just because you changed to another > intermediate protocol.
Newsreaders are designed _not_ to calculate full reachability. They would be unusable otherwise. They have reasonable heuristics for dealing with partial information and getting more only when needed.
> Yes, you could perhaps use the nntp caching, but I don't know if > you've noticed: the reason news servers tend to expire old messages > is that a news reader and the NNTP protocol won't be able to handle > huge histories either.
It's actually more of a storage problem. A pretty normal general newsspool with about 2 weeks of storage requires several gigabytes of disk space already.
> And if you just want the "expire" feature, then you might as well > just make git date-limit things for you, ie "gitk --since=last.week"
I actually don't want any "expire feature". Expiry happens at the server, and git is quite efficient enough at "storing" the articles that expiry appears pointless (unless one puts all of Sourceforge's recent commit histories onto an NNTP spool, probably an interesting experiment).
"Marked as read" could conceivably come handy for keeping on top of large projects, but basically I'd already be suited fine with ephemeral groups which look the same whenever I visit them again.
The thing with newsreaders is that it is easy to say "since last week", and then just look at a few more earlier articles. This sort of functionality has been honed and improved over decades. If I can avoid starting fresh, with a new user interface and the same old problems, that helps. Nobody wants tools that require to tell them when you start them just how much information you'll ever want from them.
That's the thing why pagers are so convenient with real pipes as compared to temporary files: you can cut off the data generating process when you decide you don't need more, and you don't need to wait until the whole data is there.
-- David Kastrup, Kriemhildstr. 15, 44793 Bochum