[U-Boot] [PATCH 00/28] u-boot next: a generic approach for nios2 arch

[Peter Tyser]

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