Hi Wolfgang, > > And I'm not entirely sure how you're proposing that a mail client > > *should* deal with such a thread. It's a tradeoff between displaying > > less of the subject text, or breaking the display of the thread > > structure earlier. Either one is going to be worse for certain inputs > > -- and given that in an actual discussion the subject doesn't often > > change, I'd rather see more of the thread structure. > > I'm not an expert in the design of MUAs, nor in user interfaces in > general. I'm using an ancient MUA myself, which has far fromperfect > threading capabilities, and usually I don;t even use a threaded > display. But when reviewing patch series, I definitely want to see the > threads of a series (and the replies to these postings) properly > threaded, which includes the correct sequence of the patches. That > means that patch N+1 must be marked as successor of patch N.
I personally think that looking at a "deep threaded" patch series with lots of responses is much harder to grasp than the "shallow threaded". As a basic example: http://article.gmane.org/gmane.comp.version-control.git/109790 I would guess that the majority of other users prefer the "shallow threaded" style too. <snip> > But then, for the MUA there is probably no way to decide which > message is the next message in the list (that should not get > indented), and which is a follow-up to one of the the messages so it > _should_ get indented. AFAICT mail headers don't carry that type of > information. I'm pretty sure in the --no-chain-reply-to case, git makes sure the email dates increment properly, and no 2 are the same. Thus any sane email client should order them properly when using shallow threading. > > > To me it makes perfect sense that a patch series is threaded - some > > > people forget to number the patches, and quite often patch arrive out > > > of order. It is much easier to have these threded correctly. > > > > So why not insist on people numbering their patches rather than creating > > a huge reply-to chain? > > I think we should have _both_. People sometimes forget something - if > you have both threading and numbering you still can reconstruct the > intended sequence. I believe the default behavior of git has also been changed to --no-chain-reply-to for what its worth. The fact that patch order can be determined by both timestamp and patch title (assuming proper generation) seems sufficient to me to use the --no-chain-reply-to option. Best, Peter _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
