Re: Can I have this, pretty please?

Linus Torvalds [off-list ref] writes:

On Sun, 12 Aug 2007, David Kastrup wrote:

quoted

quoted

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