Steven Grimm <koreth@xxxxxxxxxxxxx> writes: > David Kastrup wrote: >> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
