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

On Tue, 2009-11-10 at 13:46 -0600, Michael Witten wrote:

[Sorry about the repeat, Peter]

On Tue, Nov 10, 2009 at 1:32 AM, Peter Zijlstra [off-list ref] wrote:

quoted

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.

As can be seen in the example above, the subjects become useless at
about the 4th patch.

The reply to the first patch together with sort on subject or date also
keeps the patches in order, since consecutive patches have increasing
timestamps and properly increasing numbers in them. It also keeps the
subjects readable.

People want me to read their patches, if they make it hard on me, I
simply wont spend my time on their stuff and do something else instead.