Re: Can I have this, pretty please?

Linus Torvalds [off-list ref] writes:

On Sun, 12 Aug 2007, David Kastrup wrote:

quoted

And then it struck me: Emacs has a very efficient browser for linked
one-line information that can be expanded into complete changesets
with diffs inside.  It is called "Gnus".  A newsreader.

A newsreader is mis-designed for all the same reasons SVN is
misdesigned: it sees the messages (commits) as a _tree_.

In the first place, it sees linked messages.  They usually correspond
to something treeish, but a newsreader that would barf when they don't
would be unusable.  Newsreaders actually have to deal with stupid
things like _loops_ in message referals without going into a tizzy.
Those things happen in Usenet.

Anybody who sees development as a tree is totally bogus by
definition. It sees things forking off, but it doesn't see them
merging. That's a fundamnetal and unfixable design bug.

It is not inherent in NNTP.  It depends on the particular newsreader,
and for pretty much all of them, you can turn off threaded display if
it disturbs you.

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.  Putting every branch into a
newsgroup of its own, in contrast, together with the usual header
search and refinement options, would be _much_ _much_ faster for
accessing a particular patch.

I'll probably be able to create a Gnus _backend_ for this sort of
setup (there are even backends for directory browsing: most files
become articles written by their owner that either are plain text, or
that contain their file contents as an attachment -- quite more crazy
than a git commit tree).  But an nntp server would make the idea
usable for more than just Emacs users, and it would allow a much more
convenient "what happened on the "next" branch in the last few days"
overview than existing tools.

It lends itself not well to actually serving trees and blobs (even
though one could superficially rely on a rigid tree topology there):
newsreaders just don't match the natural way of accessing them (Gnus
offers that for files, but it plainly is not much use compared to a
dedicated directory browser).

But for commits and patches, one group per branch?  That would be
fine.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, 12 Aug 2007, David Kastrup wrote:

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.

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.

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.

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"

			Linus

On Sun, Aug 12, 2007 at 09:10:24PM +0200, David Kastrup wrote:

I'll probably be able to create a Gnus _backend_ for this sort of
setup (there are even backends for directory browsing: most files

You can somewhat prototype this by just dumping the commits to an mbox
(sorry for the long lines):

git-log \
  --pretty=format:'From %H Mon Sep 17 00:00:00 2001%nFrom: %an <%ae>%nDate: %ad%nSubject: %s%nMessage-ID: <%H@none>%nReferences: %P%n%n%b' \
  | perl -pe 's/References: (.*)/"References: " .  %join(" ", map { "<" . $_ . "\@none>" } split \/ \/, $1)/e' \
  >mbox

Looking at an appreciably large chunk of history means that you will be
very far down in a subthread. mutt, at least, doesn't display this in a
very readable way. But my point is that you are probably better to look
at a couple of different view strategies just by dumping and tweaking
the references relationships (which really only takes about a second for
me on the git.git repository).

Also, have you tried looking at tig (make sure to try a recent version
and use the 'g' command to turn on the graph display)? I think it is
similar to what you are looking for, and I have found it to be very fast
(both in implementation and in usability).

-Peff

On Sun, Aug 12, 2007 at 04:02:58PM -0400, Jeff King wrote:

git-log \
  --pretty=format:'From %H Mon Sep 17 00:00:00 2001%nFrom: %an <%ae>%nDate: %ad%nSubject: %s%nMessage-ID: <%H@none>%nReferences: %P%n%n%b' \

Er, sorry, that should be '%aD' in the date.

-Peff