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

[Peter Zijlstra <peterz@infradead.org>]

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 <peterz@infradead.org> wrote:
> > On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
> >> 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.