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

(moved from lkml to the Git list)

* Peter Zijlstra [off-list ref] wrote:

quoted

                           Mailer: 
git-send-email 1.6.5.2

Please teach your git-send-email thing to use --no-chain-reply-to.

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

and with 10 or more patches it's an absolute pain as threading depth 
increases. Furthermore, the subject lines are not aligned vertically, 
making it very hard to see the general shortlog-alike structure of the 
series, at a glance. Plus i dont even _see_ the title over a certain 
depth, as i run out of screen real estate.

So ... the question would be ... could git-send-email flip its default 
please, via the patch below? Am i missing something subtle about why 
this default was chosen?

	Ingo

Signed-off-by: Ingo Molnar <redacted>

diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..ff00940 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl

@@ -188,7 +188,7 @@ my (@suppress_cc);
 
 my %config_bool_settings = (
     "thread" => [\$thread, 1],
-    "chainreplyto" => [\$chain_reply_to, 1],
+    "chainreplyto" => [\$chain_reply_to, 0],
     "suppressfrom" => [\$suppress_from, undef],
     "signedoffbycc" => [\$signed_off_by_cc, undef],
     "signedoffcc" => [\$signed_off_by_cc, undef],      # Deprecated

On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar [off-list ref] wrote:

So ... the question would be ... could git-send-email flip its default

This is already in next for 1.7.0. See 41fe87f.

From Junio's What's Cooking messages:

* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
  (merged to 'next' on 2009-08-22 at 5106de8)

Am i missing something subtle about why this default was chosen?

I'm not sure it was chosen so much as it was just the way the cookie crumbled.

j.

* Jay Soffian [off-list ref] wrote:

On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar [off-list ref] wrote:

quoted

So ... the question would be ... could git-send-email flip its default

This is already in next for 1.7.0. See 41fe87f.

quoted

From Junio's What's Cooking messages:

* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
  (merged to 'next' on 2009-08-22 at 5106de8)

Ah, awesome!

+1 for putting it into a .1.6.x stable branch too. (Unless there's a 
case where the recursive threading is actually useful and is being 
relied on.)

	Ingo

On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:

(moved from lkml to the Git list)

* Peter Zijlstra [off-list ref] wrote:

quoted

quoted

                           Mailer: 
git-send-email 1.6.5.2

Please teach your git-send-email thing to use --no-chain-reply-to.

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.

[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.

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.