[PATCH 0/4] perf bench: Common option for specifying style formatting

[PATCH 0/4] perf bench: Common option for specifying style formatting

[Hitoshi Mitake]

This patch series adds new option "--format" to
bench subcommand of perf.

Users of perf bench will be able to specify
style formatting with this option in common way.

Hitoshi Mitake (4):
  perf bench: Add stuffs to bench.h for unified output formatting
  perf bench: Modify builtin-bench.c for processing common options
  perf bench: Modified bench/bench-messaging.c to adopt unified output
    formatting
  perf bench: Modify builtin-pipe.c for processing common options

 tools/perf/bench/bench.h           |    9 ++++
 tools/perf/bench/sched-messaging.c |   18 +++++---
 tools/perf/bench/sched-pipe.c      |   22 ++++++----
 tools/perf/builtin-bench.c         |   79 +++++++++++++++++++++++++++++------
 4 files changed, 99 insertions(+), 29 deletions(-)

[PATCH 1/4] perf bench: Add stuffs to bench.h for unified output formatting

[Hitoshi Mitake]

This patch adds some constants and extern declaration to bench.h.
These stuffs are used for unified output formatting
of 'perf bench'.

Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
---
 tools/perf/bench/bench.h |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/perf/bench/bench.h b/tools/perf/bench/bench.h
index 59adb27..42167ea 100644
--- a/tools/perf/bench/bench.h
+++ b/tools/perf/bench/bench.h
@@ -6,4 +6,13 @@ extern int bench_sched_messaging(int argc, const char **argv,
 extern int bench_sched_pipe(int argc, const char **argv,
 			    const char *prefix);
 
+#define BENCH_FORMAT_DEFAULT_STR "default"
+#define BENCH_FORMAT_DEFAULT 0
+#define BENCH_FORMAT_SIMPLE_STR "simple"
+#define BENCH_FORMAT_SIMPLE 1
+
+#define BENCH_FORMAT_UNKNOWN -1
+
+extern int bench_format;
+
 #endif
-- 
1.5.6.5

[PATCH 2/4] perf bench: Modify builtin-bench.c for processing common options

[Hitoshi Mitake]

This patch modifies builtin-bench.c for processing common options.
The first option added is "--format".
Users of perf bench will be able to specify output style by --format.

Example of use:
% ./perf bench sched messaging		# with no style specify
(20 sender and receiver processes per group)
(10 groups == 400 processes run)

        Total time:1.431 sec
% ./perf bench --format=simple sched messaging # specified simple
1.431

Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
---
 tools/perf/builtin-bench.c |   79 ++++++++++++++++++++++++++++++++++++--------
 1 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-bench.c b/tools/perf/builtin-bench.c
index 31f4164..c7505ea 100644
--- a/tools/perf/builtin-bench.c
+++ b/tools/perf/builtin-bench.c
@@ -74,53 +74,104 @@ static void dump_suites(int subsys_index)
 	return;
 }
 
+static char *bench_format_str;
+int bench_format = BENCH_FORMAT_DEFAULT;
+
+static const struct option bench_options[] = {
+	OPT_STRING('f', "format", &bench_format_str, "default",
+		    "Specify format style"),
+	OPT_END()
+};
+
+static const char * const bench_usage[] = {
+	"perf bench [<common options>] <subsystem> <suite> [<options>]",
+	NULL
+};
+
+static void print_usage(void)
+{
+	int i;
+
+	printf("Usage: \n");
+	for (i = 0; bench_usage[i]; i++)
+		printf("\t%s\n", bench_usage[i]);
+	printf("\n");
+
+	printf("List of available subsystems...\n\n");
+
+	for (i = 0; subsystems[i].name; i++)
+		printf("\t%s: %s\n",
+		       subsystems[i].name, subsystems[i].summary);
+	printf("\n");
+}
+
+static int bench_str2int(char *str)
+{
+	if (!str)
+		return BENCH_FORMAT_DEFAULT;
+
+	if (!strcmp(str, BENCH_FORMAT_DEFAULT_STR))
+		return BENCH_FORMAT_DEFAULT;
+	else if (!strcmp(str, BENCH_FORMAT_SIMPLE_STR))
+		return BENCH_FORMAT_SIMPLE;
+
+	return BENCH_FORMAT_UNKNOWN;
+}
+
 int cmd_bench(int argc, const char **argv, const char *prefix __used)
 {
 	int i, j, status = 0;
 
 	if (argc < 2) {
 		/* No subsystem specified. */
-		printf("Usage: perf bench <subsystem> <suite> [<options>]\n\n");
-		printf("List of available subsystems...\n\n");
+		print_usage();
+		goto end;
+	}
 
-		for (i = 0; subsystems[i].name; i++)
-			printf("\t%s: %s\n",
-			       subsystems[i].name, subsystems[i].summary);
-		printf("\n");
+	argc = parse_options(argc, argv, bench_options, bench_usage,
+			     PARSE_OPT_STOP_AT_NON_OPTION);
+
+	bench_format = bench_str2int(bench_format_str);
+	if (bench_format == BENCH_FORMAT_UNKNOWN) {
+		printf("Unknown format descriptor:%s\n", bench_format_str);
+		goto end;
+	}
 
+	if (argc < 1) {
+		print_usage();
 		goto end;
 	}
 
 	for (i = 0; subsystems[i].name; i++) {
-		if (strcmp(subsystems[i].name, argv[1]))
+		if (strcmp(subsystems[i].name, argv[0]))
 			continue;
 
-		if (argc < 3) {
+		if (argc < 2) {
 			/* No suite specified. */
 			dump_suites(i);
 			goto end;
 		}
 
 		for (j = 0; subsystems[i].suites[j].name; j++) {
-			if (strcmp(subsystems[i].suites[j].name, argv[2]))
+			if (strcmp(subsystems[i].suites[j].name, argv[1]))
 				continue;
 
-			status = subsystems[i].suites[j].fn(argc - 2,
-							    argv + 2, prefix);
+			status = subsystems[i].suites[j].fn(argc - 1,
+							    argv + 1, prefix);
 			goto end;
 		}
 
-		if (!strcmp(argv[2], "-h") || !strcmp(argv[2], "--help")) {
+		if (!strcmp(argv[1], "-h") || !strcmp(argv[1], "--help")) {
 			dump_suites(i);
 			goto end;
 		}
 
-		printf("Unknown suite:%s for %s\n", argv[2], argv[1]);
+		printf("Unknown suite:%s for %s\n", argv[1], argv[0]);
 		status = 1;
 		goto end;
 	}
 
-	printf("Unknown subsystem:%s\n", argv[1]);
+	printf("Unknown subsystem:%s\n", argv[0]);
 	status = 1;
 
 end:
-- 
1.5.6.5

[PATCH 3/4] perf bench: Modified bench/bench-messaging.c to adopt unified output formatting

[Hitoshi Mitake]

This patch modifies bench/bench-messaging.c to adopt
unified output formatting: --format option.

Example of use:
% ./perf bench sched messaging              # with no style specify
(20 sender and receiver processes per group)
(10 groups == 400 processes run)

        Total time:1.431 sec
% ./perf bench --format=simple sched messaging # specified simple
1.431

Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
---
 tools/perf/bench/sched-messaging.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/tools/perf/bench/sched-messaging.c b/tools/perf/bench/sched-messaging.c
index 36b62c5..2cc5edc 100644
--- a/tools/perf/bench/sched-messaging.c
+++ b/tools/perf/bench/sched-messaging.c
@@ -35,7 +35,6 @@ static int use_pipes = 0;
 static unsigned int loops = 100;
 static unsigned int thread_mode = 0;
 static unsigned int num_groups = 10;
-static int simple = 0;
 
 struct sender_context {
 	unsigned int num_fds;
@@ -261,9 +260,6 @@ static const struct option options[] = {
 		    "Specify number of groups"),
 	OPT_INTEGER('l', "loop", &loops,
 		    "Specify number of loops"),
-	OPT_BOOLEAN('s', "simple-output", &simple,
-		    "Do simple output (this maybe useful for"
-		    "processing by scripts or graph tools like gnuplot)"),
 	OPT_END()
 };
 
@@ -316,9 +312,8 @@ int bench_sched_messaging(int argc, const char **argv,
 
 	timersub(&stop, &start, &diff);
 
-	if (simple)
-		printf("%lu.%03lu\n", diff.tv_sec, diff.tv_usec/1000);
-	else {
+	switch (bench_format) {
+	case BENCH_FORMAT_DEFAULT:
 		printf("(%d sender and receiver %s per group)\n",
 		       num_fds, thread_mode ? "threads" : "processes");
 		printf("(%d groups == %d %s run)\n\n",
@@ -326,6 +321,15 @@ int bench_sched_messaging(int argc, const char **argv,
 		       thread_mode ? "threads" : "processes");
 		printf("\tTotal time:%lu.%03lu sec\n",
 		       diff.tv_sec, diff.tv_usec/1000);
+		break;
+	case BENCH_FORMAT_SIMPLE:
+		printf("%lu.%03lu\n", diff.tv_sec, diff.tv_usec/1000);
+		break;
+	default:
+		/* reaching here is something disaster */
+		fprintf(stderr, "Unknown format:%d\n", bench_format);
+		exit(1);
+		break;
 	}
 
 	return 0;
-- 
1.5.6.5

[PATCH 4/4] perf bench: Modify builtin-pipe.c for processing common options

[Hitoshi Mitake]

This patch modifies builtin-pipe.c for processing common options.
The first option added is "--format".
Users of perf bench will be able to specify output style by --format.

Example of use:
% ./perf bench sched pipe		# with no style specify
(executing 1000000 pipe operations between two tasks)

        Total time:5.855 sec
                5.855061 usecs/op
                170792 ops/sec
% ./perf bench --format=simple sched pipe # specified simple
5.988

Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
---
 tools/perf/bench/sched-pipe.c |   22 ++++++++++++++--------
 1 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 6a29100..a9ac186 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -30,14 +30,10 @@
 
 #define LOOPS_DEFAULT 1000000
 static int loops = LOOPS_DEFAULT;
-static int simple = 0;
 
 static const struct option options[] = {
 	OPT_INTEGER('l', "loop", &loops,
 		    "Specify number of loops"),
-	OPT_BOOLEAN('s', "simple-output", &simple,
-		    "Do simple output (this maybe useful for"
-		    "processing by scripts or graph tools like gnuplot)"),
 	OPT_END()
 };
 
@@ -94,10 +90,8 @@ int bench_sched_pipe(int argc, const char **argv,
 		return 0;
 	}
 
-	if (simple)
-		printf("%lu.%03lu\n",
-		       diff.tv_sec, diff.tv_usec / 1000);
-	else {
+	switch (bench_format) {
+	case BENCH_FORMAT_DEFAULT:
 		printf("(executing %d pipe operations between two tasks)\n\n",
 			loops);
 
@@ -111,6 +105,18 @@ int bench_sched_pipe(int argc, const char **argv,
 		printf("\t\t%d ops/sec\n",
 		       (int)((double)loops /
 			     ((double)result_usec / (double)1000000)));
+		break;
+
+	case BENCH_FORMAT_SIMPLE:
+		printf("%lu.%03lu\n",
+		       diff.tv_sec, diff.tv_usec / 1000);
+		break;
+
+	default:
+		/* reaching here is something disaster */
+		fprintf(stderr, "Unknown format:%d\n", bench_format);
+		exit(1);
+		break;
 	}
 
 	return 0;
-- 
1.5.6.5

Re: [PATCH 0/4] perf bench: Common option for specifying style formatting

[Peter Zijlstra]

On Tue, 2009-11-10 at 02:03 +0900, Hitoshi Mitake wrote:
>                            Mailer: 
> git-send-email 1.6.5.2

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

Re: [PATCH 0/4] perf bench: Common option for specifying style formatting

[Hitoshi Mitake]

From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 0/4] perf bench: Common option for specifying style formatting
Date: Mon, 09 Nov 2009 18:59:15 +0100

> On Tue, 2009-11-10 at 02:03 +0900, Hitoshi Mitake wrote:
> >                            Mailer: 
> > git-send-email 1.6.5.2
> 
> Please teach your git-send-email thing to use --no-chain-reply-to.

Sorry, I'll send version 2 with --no-chain-reply-to.

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

> (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

[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

[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

[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

[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

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