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

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

[Ingo Molnar]

(moved from lkml to the Git list)

* Peter Zijlstra <peterz@infradead.org> wrote:

> >                            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 <mingo@elte.hu>

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

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

[Jay Soffian]

On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar <mingo@elte.hu> 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.

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

[Ingo Molnar]

* Jay Soffian <jaysoffian@gmail.com> wrote:

> On Mon, Nov 9, 2009 at 11:08 PM, Ingo Molnar <mingo@elte.hu> 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)

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

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

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> writes:

> +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.)

As I wrote in the LKML message when that patch was made (please see my
other message for the URL to the archive), my assessment of this issue is
that it would have been the right thing to do if we were doing this now
without any existing users, but nobody really cares deeply enough either
way to warrant fast tracking the schedule we promised back in August.

It would take a bit stronger nudging than "unless there is a case against
changing the default because it is being relied on", as I know that people
who rely on would not speak up for a long time.  We already saw that it
took 6 month between Feb 2009 to Aug 2009 for people who wanted to change
the default to notice and complain that the change they were promised did
not happen ;-).

Some people will complain when we switch the default to no-chain-reply-to
in the 1.7.0 release.  I am willing to take flak from them and defend the
change.

But I am not convinced that this deserves to be fast-tracked to the 1.6.x
series.  We gave them until 1.7.0 and I have no good answer to "why didn't
you wait as you promised?"  I'd rather avoid telling them that "that is
how kernel people wanted it, and sorry, their wish trumps yours." if I
can.

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

[Junio C Hamano]

Ingo Molnar <mingo@elte.hu> writes:

> (moved from lkml to the Git list)
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
>> >                            Mailer: 
>> > git-send-email 1.6.5.2
>> 
>> Please teach your git-send-email thing to use --no-chain-reply-to.
> ...
> 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?

I do not think there was any conscious decision made when the
chain-reply-to was added.  It was done and it got stuck.

I think the _only_ argument anybody _could_ make (and I won't be making
it, as I'd rather wish we had no-chain-reply-to the default from day one)
against the change of default is that it is a change [*1*].

Lkml already had two rather heated discussion in the past,

After the first round, I said we'd change the default to no-chain-reply-to
in release 1.6.3 unless somebody makes a convincing argument why the
default should not change, back around the time we were preparing for
1.6.2 (February 2009).

    http://thread.gmane.org/gmane.comp.version-control.git/109790

Nobody complained.

Then I forgot to make such a declaration in the release notes to 1.6.3,
and no such declaration appeard in later release notes, either.

But nobody complained (nor reminded me).

The second round of the discussion was in August 2009.  This time I did
something to prevent me from forgetting in the future.

    http://thread.gmane.org/gmane.linux.kernel/879975/focus=880938

This patch is queued in 'next', scheduled to graduate to 'master' for the
1.7.0 release.


[Footnote]

*1* To spell it out...  The people who are in the "hate chain-reply-to
very much" camp would have already done their own configuration to get the
behaviour they want by now, so changing the default would not help them
much, while potentially hurting "love chain-reply-to" people who have been
content because they got what they wanted without setting any
configuration.

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

[Ingo Molnar]

* Junio C Hamano <gitster@pobox.com> wrote:

> [Footnote]
> 
> *1* To spell it out...  The people who are in the "hate chain-reply-to 
> very much" camp would have already done their own configuration to get 
> the behaviour they want by now, so changing the default would not help 
> them much, while potentially hurting "love chain-reply-to" people who 
> have been content because they got what they wanted without setting 
> any configuration.

Stupid question: i researched the Git mailing list archive (and read the 
link you provided) and found no arguments (at all) in favor of the 
nested chaining. Are you aware of any?

And i dont 'hate' it - i am just the one suffering from it as a 
maintainer. _I_ can certainly fix my scripts as you suggest above, but 
that is not my problem: my problem are the many people sending 
first-time Git based patch series to me (and there's quite a few of 
them) always, in every single case, get it wrong.

The ones not using Git (using Quilt for example) and sending me series 
get it right in pretty much every case.

So i can see it when developers start using Git to submit patches - in 
each and every case - the discussion threading is all messed up ;-)

These people dont 'do their own configuration' - they are mostly newbies 
or developrs new to Git workflows. And the first reaction they get from 
their upstream maintainer counterpart is some grumbling about the 
threading. Not good, me thinks ;-)

	Ingo

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

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Junio C Hamano <gitster@pobox.com> wrote:
> 
> > [Footnote]
> > 
> > *1* To spell it out...  The people who are in the "hate 
> > chain-reply-to very much" camp would have already done their own 
> > configuration to get the behaviour they want by now, so changing the 
> > default would not help them much, while potentially hurting "love 
> > chain-reply-to" people who have been content because they got what 
> > they wanted without setting any configuration.
> 
> Stupid question: i researched the Git mailing list archive (and read 
> the link you provided) and found no arguments (at all) in favor of the 
> nested chaining. Are you aware of any?

Btw., dont get me wrong - i'm perfectly happy with the fix in 1.7.0. You 
are also right that behavioral changes dont belong into stable releases.

( I'm just seeing this problem through the biased eyes of someone who is
  affected by it, so i naturally want to have the benefit of the change
  ASAP - without fully perceiving the risks of the change.)

Thanks,

	Ingo

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

[Peter Zijlstra]

On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
> (moved from lkml to the Git list)
> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > >                            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.

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

[Michael Witten]

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

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

[Peter Zijlstra]

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.