Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

Re: [RFC, PATCH] git send-email: Make --no-chain-reply-to the default

From: Michael Witten <hidden>
Date: 2016-06-15 22:47:42

Possibly related (same subject, not in this thread)

[Sorry about the repeat, Peter]

On Tue, Nov 10, 2009 at 1:32 AM, Peter Zijlstra [off-list ref] wrote:
On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
quoted
about half of every patch series that gets sent to me on lkml is
unreadable in my email client due to the default threading that
git-send-email does. It looks like this:

28685 r T Nov 05 Hitoshi Mitake  (  31) [PATCH v5 0/7] Adding general performance benchmarki
28686   T Nov 05 Hitoshi Mitake  (  31) +->[PATCH v5 1/7] Adding new directory and header fo
28687   T Nov 05 Hitoshi Mitake  ( 368) | +->[PATCH v5 2/7] sched-messaging.c: benchmark for
28688   T Nov 05 Hitoshi Mitake  ( 148) | | +->[PATCH v5 3/7] sched-pipe.c: benchmark for pi
28689   T Nov 05 Hitoshi Mitake  ( 149) | | | +->[PATCH v5 4/7] builtin-bench.c: General fra
28690   T Nov 05 Hitoshi Mitake  (  24) | | | | +->[PATCH v5 5/7] Modifying builtin.h for ne
28691   T Nov 05 Hitoshi Mitake  (  25) | | | | | +->[PATCH v5 6/7] Modyfing perf.c for subc
28692   T Nov 05 Hitoshi Mitake  (  30) | | | | | | +->[PATCH v5 7/7] Modyfing Makefile to b
Do what I do and flame the sender and have them repost.

I simply won't even attempt to read crap send like that.
What, precisely, is unreadable or crappy about that? I suppose the
chaining was introduced to keep some order to the patches.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help