threads / rfc / 21554

RFC patchgit send-email: Make --no-chain-reply-to the default

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

## tl;dr

10 messages between Nov 10, 2009 and Nov 10, 2009. Diffs are folded; open one to read it.

replies: 9people: 5as markdown or json

Ingo Molnar· Nov 10, 2009, 04:08 UTC · lore
(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>
Show changes to git-send-email.perl +1 −1
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
Jay Soffian· Nov 10, 2009, 05:12 UTC · re: Ingo Molnar · lore

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

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.
Ingo Molnar· Nov 10, 2009, 05:22 UTC · re: Jay Soffian · lore

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

* Jay Soffian <jaysoffian@gmail.com> wrote:
Show 9 quoted lines
> 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
Junio C Hamano· Nov 10, 2009, 06:05 UTC · re: Ingo Molnar · lore

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

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.

Junio C Hamano· Nov 10, 2009, 05:29 UTC · re: Ingo Molnar · lore

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

Ingo Molnar <mingo@elte.hu> writes:
Show 12 quoted lines
> (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.

Ingo Molnar· Nov 10, 2009, 07:19 UTC · re: Junio C Hamano · lore

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

* Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> [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
Ingo Molnar· Nov 10, 2009, 18:29 UTC · re: Ingo Molnar · lore

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

* Ingo Molnar <mingo@elte.hu> wrote:
Show 14 quoted lines
> * 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
Peter Zijlstra· Nov 10, 2009, 07:32 UTC · re: Ingo Molnar · lore

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

On Tue, 2009-11-10 at 05:08 +0100, Ingo Molnar wrote:
Show 21 quoted lines
> (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.
Michael Witten· Nov 10, 2009, 19:46 UTC · re: Peter Zijlstra · lore

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

[Sorry about the repeat, Peter]
On Tue, Nov 10, 2009 at 1:32 AM, Peter Zijlstra <peterz@infradead.org> wrote:
Show 17 quoted lines
> 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.

Peter Zijlstra· Nov 10, 2009, 19:58 UTC · re: Michael Witten · lore

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:
Show 23 quoted lines
> [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.

← back to recent threads