Re: Can I have this, pretty please?

Steven Grimm [off-list ref] writes:

David Kastrup wrote:

quoted

Mapping a repository into newsgroups (one per branch head?), complete
with threads, references, header display, article fetch (by
git-format-patch), Message Ids (=commit id) is much more
straightforward than creating an HTML server.  And it means that
everybody can use his favorite newsreader for navigating a repository.

The news data model has one big problem. It is a tree structure (or
rather, a set of tree structures). But git's ancestry graphs are not
trees; a commit can have multiple parents as well as multiple
children, and branches can join each other multiple times (via merges)
as well as split off indefinitely.

I realize that you can give a list of parent message IDs in a news
header, but I'm going to go out on a limb and guess that all
existing newsreaders expect that list to be a linear series of
messages going back toward the root of the thread (since that's all
that ever occurs in real netnews), rather than an arbitrary DAG.

Well, I never claimed that the threading display would necessarily be
correct.  But with most readers, you can turn it off.  And you can
even tell git to turn off merges in the revision lists.  After all, it
has to linearize things like "whatchanged", too.

Not saying it's a worthless idea, but I bet you will not be able to
get an accurate display of a repository's history using a news
reader without modifying it to deal with more complex ancestry
structures.

It would still be lots more convenient for finding one's way around
patch series than the current model.  And putting out every branch
into a group of its own (which makes merges somewhat close to
crosspostings in that the reader will not usually try tracking the
changes in the other group) would help keeping the peculiarities in a
single branch display limited.

At the current point of time, _all_ tools I have available for
browsing the history of a large project like Emacs suck _big_ time
compared to what my newsreader can handle.  They render my system
(256MB, about 1GHz) unusable if they work at all.  Being able to, say,
cherrypick stuff together by marking articles and piping the bunch
through git-am (which is what I sometimes do with articles on the git
list) would be quite nice.

And the charm over an http server is that an nntp server can basically
just serve git data raw, without the necessity to add any dressing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum