git-send-email

git-send-email

[Peter Zijlstra]

Hi,

could we change the default of git-send-email to --no-chain-reply-to?
These incredibly deep mail threads are a nuisance.

Re: git-send-email

[Ingo Oeser]

Hi,

On Thursday 12 February 2009, Peter Zijlstra wrote:
> could we change the default of git-send-email to --no-chain-reply-to?
> These incredibly deep mail threads are a nuisance.

No, they are great, if you like to skip over a topic, you are not
interested in at all!

If you don't like it, just switch off thread in your mailer and
don't force this on everybody else!

Best Regards

Ingo Oeser

Re: git-send-email

[Peter Zijlstra]

On Thu, 2009-02-12 at 18:25 +0100, Ingo Oeser wrote:
> Hi,
> 
> On Thursday 12 February 2009, Peter Zijlstra wrote:
> > could we change the default of git-send-email to --no-chain-reply-to?
> > These incredibly deep mail threads are a nuisance.
> 
> No, they are great, if you like to skip over a topic, you are not
> interested in at all!

A single depth thread can do that too.

> If you don't like it, just switch off thread in your mailer and
> don't force this on everybody else!

That's something quite different. I quite like the subject grouping,
what I don't like is not being able to read distinct subject lines
because the n-th email in the patch series in so deep the threading in
my mailer can't display the subject anymore.

Re: git-send-email

[Lennart Sorensen]

On Thu, Feb 12, 2009 at 06:25:34PM +0100, Ingo Oeser wrote:
> No, they are great, if you like to skip over a topic, you are not
> interested in at all!
> 
> If you don't like it, just switch off thread in your mailer and
> don't force this on everybody else!

Actually if (as apparently many people seem to manage to do) you have a
single starting email, with all the patches as replies to that first
email, it looks a lot better, and is much easier to follow.

Seperate threads would be bad.

foobar patch 0 (usually a summary/overview)
+-foobar patch 1
+-foobar patch 2
+-foobar patch 3
+-foobar patch 4
+-foobar patch 5

is much nicer than

foobar patch 0
+-foobar patch 1
  +-foobar patch 2
    +-foobar patch 3
      +-foobar patch 4
        +-foobar patch 5

which seems to be what git does itself.

-- 
Len Sorensen

Re: git-send-email

[Peter Zijlstra]

On Thu, 2009-02-12 at 14:21 -0500, Lennart Sorensen wrote:
> On Thu, Feb 12, 2009 at 06:25:34PM +0100, Ingo Oeser wrote:
> > No, they are great, if you like to skip over a topic, you are not
> > interested in at all!
> > 
> > If you don't like it, just switch off thread in your mailer and
> > don't force this on everybody else!
> 
> Actually if (as apparently many people seem to manage to do) you have a
> single starting email, with all the patches as replies to that first
> email, it looks a lot better, and is much easier to follow.
> 
> Seperate threads would be bad.
> 
> foobar patch 0 (usually a summary/overview)
> +-foobar patch 1
> +-foobar patch 2
> +-foobar patch 3
> +-foobar patch 4
> +-foobar patch 5
> 
> is much nicer than
> 
> foobar patch 0
> +-foobar patch 1
>   +-foobar patch 2
>     +-foobar patch 3
>       +-foobar patch 4
>         +-foobar patch 5
> 
> which seems to be what git does itself.

Which happens to be exactly what my suggestion would accomplish.

--[no-]chain-reply-to
        
        If this is set, each email will be sent as a reply to the
        previous email sent. If disabled with "--no-chain-reply-to", all
        emails after the first will be sent as replies to the first
        email sent. When using this, it is recommended that the first
        file given be an overview of the entire patch series. Default is
        the value of the sendemail.chainreplyto configuration value; if
        that is unspecified, default to --chain-reply-to.
        
        

Re: git-send-email

[Junio C Hamano]

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:

> On Thu, Feb 12, 2009 at 06:25:34PM +0100, Ingo Oeser wrote:
>> No, they are great, if you like to skip over a topic, you are not
>> interested in at all!
>> 
>> If you don't like it, just switch off thread in your mailer and
>> don't force this on everybody else!
>
> Actually if (as apparently many people seem to manage to do) you have a
> single starting email, with all the patches as replies to that first
> email, it looks a lot better, and is much easier to follow.
>
> Seperate threads would be bad.
>
> foobar patch 0 (usually a summary/overview)
> +-foobar patch 1
> +-foobar patch 2
> +-foobar patch 3
> +-foobar patch 4
> +-foobar patch 5
>
> is much nicer than
>
> foobar patch 0
> +-foobar patch 1
>   +-foobar patch 2
>     +-foobar patch 3
>       +-foobar patch 4
>         +-foobar patch 5
>
> which seems to be what git does itself.

I personally prefer the former, but as you hopefully all found out by now,
the choice between these two is just the matter of personal taste, and
there is no clear majority.

The default will not going to change.

Re: git-send-email

[Peter Zijlstra]

On Thu, 2009-02-12 at 18:16 -0800, Junio C Hamano wrote:
> lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:
> 
> > On Thu, Feb 12, 2009 at 06:25:34PM +0100, Ingo Oeser wrote:
> >> No, they are great, if you like to skip over a topic, you are not
> >> interested in at all!
> >> 
> >> If you don't like it, just switch off thread in your mailer and
> >> don't force this on everybody else!
> >
> > Actually if (as apparently many people seem to manage to do) you have a
> > single starting email, with all the patches as replies to that first
> > email, it looks a lot better, and is much easier to follow.
> >
> > Seperate threads would be bad.
> >
> > foobar patch 0 (usually a summary/overview)
> > +-foobar patch 1
> > +-foobar patch 2
> > +-foobar patch 3
> > +-foobar patch 4
> > +-foobar patch 5
> >
> > is much nicer than
> >
> > foobar patch 0
> > +-foobar patch 1
> >   +-foobar patch 2
> >     +-foobar patch 3
> >       +-foobar patch 4
> >         +-foobar patch 5
> >
> > which seems to be what git does itself.
> 
> I personally prefer the former, but as you hopefully all found out by now,
> the choice between these two is just the matter of personal taste, and
> there is no clear majority.
> 
> The default will not going to change.

Its a matter of usability, the inf deep chain git does by default
renders the result unusable. Fact is I usually skip over patch series
posted that way, simply because its too much of a bother.

If you can't be bothered with usability of your project, then so be it.
Maybe all those rants on how unusable git is have a point after all.

Re: git-send-email

[Willy Tarreau]

Hi Peter,

On Fri, Feb 13, 2009 at 10:22:38AM +0100, Peter Zijlstra wrote:
> On Thu, 2009-02-12 at 18:16 -0800, Junio C Hamano wrote:
> > lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:
> > 
> > > On Thu, Feb 12, 2009 at 06:25:34PM +0100, Ingo Oeser wrote:
> > >> No, they are great, if you like to skip over a topic, you are not
> > >> interested in at all!
> > >> 
> > >> If you don't like it, just switch off thread in your mailer and
> > >> don't force this on everybody else!
> > >
> > > Actually if (as apparently many people seem to manage to do) you have a
> > > single starting email, with all the patches as replies to that first
> > > email, it looks a lot better, and is much easier to follow.
> > >
> > > Seperate threads would be bad.
> > >
> > > foobar patch 0 (usually a summary/overview)
> > > +-foobar patch 1
> > > +-foobar patch 2
> > > +-foobar patch 3
> > > +-foobar patch 4
> > > +-foobar patch 5
> > >
> > > is much nicer than
> > >
> > > foobar patch 0
> > > +-foobar patch 1
> > >   +-foobar patch 2
> > >     +-foobar patch 3
> > >       +-foobar patch 4
> > >         +-foobar patch 5
> > >
> > > which seems to be what git does itself.
> > 
> > I personally prefer the former, but as you hopefully all found out by now,
> > the choice between these two is just the matter of personal taste, and
> > there is no clear majority.
> > 
> > The default will not going to change.
> 
> Its a matter of usability, the inf deep chain git does by default
> renders the result unusable. Fact is I usually skip over patch series
> posted that way, simply because its too much of a bother.
> 
> If you can't be bothered with usability of your project, then so be it.
> Maybe all those rants on how unusable git is have a point after all.

While your last comment seems a bit excessive to me, I agree with you
about the threading problem. I have to turn threads off to read some
of these long mails because the subject does not fit in my terminal,
and most of the time I only see just something like '[PATCH' which is
pretty useless.

The former mode (as used by Greg when he posts his huge stable series)
is a lot more convenient. Also, if one mail gets dropped for whatever
reason in between, the threading is not broken.

Regards,
Willy

Re: git-send-email

[Ingo Oeser]

On Thursday 12 February 2009, Peter Zijlstra wrote:
> > foobar patch 0 (usually a summary/overview)
> > +-foobar patch 1
> > +-foobar patch 2
> > +-foobar patch 3
> > +-foobar patch 4
> > +-foobar patch 5
> > 
> > is much nicer than
> > 
> > foobar patch 0
> > +-foobar patch 1
> >   +-foobar patch 2
> >     +-foobar patch 3
> >       +-foobar patch 4
> >         +-foobar patch 5
> > 
> > which seems to be what git does itself.
> 
> Which happens to be exactly what my suggestion would accomplish.

Ok, then I take back my reservations and support this idea.

Lennart: Thanks for visualizing what Peter meant :-)

Best Regards

Ingo Oeser

Re: git-send-email

[Lennart Sorensen]

On Fri, Feb 13, 2009 at 10:34:05AM +0100, Ingo Oeser wrote:
> On Thursday 12 February 2009, Peter Zijlstra wrote:
> > > foobar patch 0 (usually a summary/overview)
> > > +-foobar patch 1
> > > +-foobar patch 2
> > > +-foobar patch 3
> > > +-foobar patch 4
> > > +-foobar patch 5
> > > 
> > > is much nicer than
> > > 
> > > foobar patch 0
> > > +-foobar patch 1
> > >   +-foobar patch 2
> > >     +-foobar patch 3
> > >       +-foobar patch 4
> > >         +-foobar patch 5
> > > 
> > > which seems to be what git does itself.
> > 
> > Which happens to be exactly what my suggestion would accomplish.
> 
> Ok, then I take back my reservations and support this idea.
> 
> Lennart: Thanks for visualizing what Peter meant :-)

Just in case anyone cares here are some statistics.  I grabbed lkml
traffic from early january to early feburary, and looked at all the
multi message patches and split them into the 3 categories split,
shallow and deep.  That means:

  Split: (multiple seperate threads)
  foobar patch 1
  +-comment on patch 1
  foobar patch 2
  foobar patch 3
  +-comment on patch 3
  foobar patch 4
  foobar patch 5

  Shallow: (A tree of patches, with all patches linked from a single start message)
  foobar patch 0 (usually a summary/overview)
  +-foobar patch 1
  | +-comment on patch 1
  +-foobar patch 2
  +-foobar patch 3
  | +-comment on patch 3
  +-foobar patch 4
  +-foobar patch 5

  Deep: (One long chain of patches)
  foobar patch 0
  +-foobar patch 1
    +-foobar patch 2
    | +-foobar patch 3
    |   +-foobar patch 4
    |   | +-foobar patch 5
    |   +-comment on patch 3
    +-comment on patch 1

So the results were that people had used:
Split: 25 patch sets.
Shallow: 56 patch sets.
Deep: 6 patch sets.

It certainly looks like the shallow threaded mode is by far the most
prefered style by kernel developers, and should perhaps be the default
in GIT, especially given it makes it harder to follow the thread (later
patches are seen before comments on a patch, and the thread gets very
wide on the screen.  I suspect almost all if not all of the users of the
default deep method, do it because its the default and not by choice.  I
doubt whoever implemented the feature in git had even though about what
would happen when someone did a 50 part patch set that way.  It may even
be that some people use the split style because they don't like the deep
style and git doesn't support doing the shalow style that most people
prefer.

Fortunately the people responsible for posting the largest patch sets
(such as stable reviews and the like) are doing it with shallow stule
already, however they manage to do that.  Yay!

Oh well, back to doing actual useful work again...

-- 
Len Sorensen

Re: git-send-email

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> I personally prefer the former, but as you hopefully all found out by now,
> the choice between these two is just the matter of personal taste, and
> there is no clear majority.
> 

Quite on the contrary.  I think there is a clear majority in favor of
--no-chain-reply-to.  Let me add my voice to that chorus, too.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: git-send-email

[Cyrill Gorcunov]

[H. Peter Anvin - Fri, Feb 13, 2009 at 10:13:16AM -0800]
| Junio C Hamano wrote:
| > 
| > I personally prefer the former, but as you hopefully all found out by now,
| > the choice between these two is just the matter of personal taste, and
| > there is no clear majority.
| > 
| 
| Quite on the contrary.  I think there is a clear majority in favor of
| --no-chain-reply-to.  Let me add my voice to that chorus, too.
| 
| 	-hpa
| 
| -- 
| H. Peter Anvin, Intel Open Source Technology Center
| I work for Intel.  I don't speak on their behalf.
| 

If that somehow matter -- I'm _for_ --no-chain-reply-to
by default too. It happens several times with me that
I missed this option even having in mind --no-chain-reply-to
behaviour expected.

On the other hand I think --no-chain-reply-to has much
sense if pathes being sent are not numbered in title.
But on LKML I can't remember even one mail-thread which was
not numbered :)

	- Cyrill -

Re: git-send-email

[Junio C Hamano]

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) writes:

> Split: 25 patch sets.
> Shallow: 56 patch sets.
> Deep: 6 patch sets.

This is an interesting datapoint.

FWIW, for the git mailing list, the stats are like Shallow=30 vs Deep=50
for a series longer than 3 patches (I stopped counting after looking at
5200 messages).

But I think these numbers are flawed, as it is very likely that much more
people on the git mailing list are using git-send-email, while on the
kernel list, a lot of patches do not even come from git.  To put it
another way, we shouldn't take the numbers from the git mailing list
samples as an indicator on the style preferred by the *readers*.  The
numbers that can be counted only show what the *senders* thought would be
acceptable to the readers, nothing more.

If you are advocating to change the default, please take the discussion to
the git mailing list.  As I already said, I personally am in favor of the
shallow kind, but I do not run dictatorship over there.

Also we cannot make a change based solely on what the kernel people have
recently done these days; it is not year 2005 anymore and git is used by
other projects as well.

Just like the kernel folks take regressions seriously to the point to say
breaking one person's working setup is worse than fixing a known bug that
affects many more people, I take changing any default seriously.  Most
discussions to change the default come from poeple who do not like the
default for obvious reasons, and it is difficult to judge if there is a
silent majority that is content with the current behaviour, or everybody
is unhappy but only some care deeply enough to make loud noises about it.
We cannot tell these two cases apart very easily by only listening to the
loudness of voices of complaining people.

Thanks.

Re: git-send-email

[Stefan Richter]

Junio C Hamano wrote:
> Just like the kernel folks take regressions seriously to the point to say
> breaking one person's working setup is worse than fixing a known bug that
> affects many more people,

BTW, from the manual:

       --chain-reply-to, --no-chain-reply-to
           [...] Default is the value of the sendemail.chainreplyto
           configuration value; if that is unspecified, default to
           --chain-reply-to.

Everybody who isn't afraid of configuration files can implement his
preferred default easily.
-- 
Stefan Richter
-=====-==--= --=- -====
http://arcgraph.de/sr/

Re: git-send-email

[Peter Zijlstra]

On Sun, 2009-02-15 at 18:20 +0100, Stefan Richter wrote:
> Junio C Hamano wrote:
> > Just like the kernel folks take regressions seriously to the point to say
> > breaking one person's working setup is worse than fixing a known bug that
> > affects many more people,
> 
> BTW, from the manual:
> 
>        --chain-reply-to, --no-chain-reply-to
>            [...] Default is the value of the sendemail.chainreplyto
>            configuration value; if that is unspecified, default to
>            --chain-reply-to.
> 
> Everybody who isn't afraid of configuration files can implement his
> preferred default easily.

Yep, trouble is with all those folks who

 1) don't know about the option
 2) aren't educated to know its a good idea to use it

So by changing the default we're better off all around.

Re: git-send-email

[Stefan Richter]

Peter Zijlstra wrote:
> On Sun, 2009-02-15 at 18:20 +0100, Stefan Richter wrote:
>> from the manual:
>>
>>        --chain-reply-to, --no-chain-reply-to
>>            [...] Default is the value of the sendemail.chainreplyto
>>            configuration value; if that is unspecified, default to
>>            --chain-reply-to.
>>
>> Everybody who isn't afraid of configuration files can implement his
>> preferred default easily.
> 
> Yep, trouble is with all those folks who
> 
>  1) don't know about the option
>  2) aren't educated to know its a good idea to use it
> 
> So by changing the default we're better off all around.

There will always be trouble with these folks. ;-)

Two more thoughts:  Since git-send-email puts sequence information into
the Subject header, additional sequence info in the References header is
redundant.  It is sufficient that the References or In-Reply-To header
carries information about which mail thread a posting belongs to.

On the other hand, --no-chain-reply-to makes less sense if the thread
starts with a 1/n posting instead of an introductory 0/n one.

(What if git-send-email could optionally generate a 0/n posting with
shortlog and combined diffstat as default content?)
-- 
Stefan Richter
-=====-==--= --=- -====
http://arcgraph.de/sr/

Re: git-send-email

[Joel Becker]

On Sun, Feb 15, 2009 at 06:20:20PM +0100, Stefan Richter wrote:
> Junio C Hamano wrote:
> > Just like the kernel folks take regressions seriously to the point to say
> > breaking one person's working setup is worse than fixing a known bug that
> > affects many more people,
> 
> BTW, from the manual:
> 
>        --chain-reply-to, --no-chain-reply-to
>            [...] Default is the value of the sendemail.chainreplyto
>            configuration value; if that is unspecified, default to
>            --chain-reply-to.
> 
> Everybody who isn't afraid of configuration files can implement his
> preferred default easily.

	Actually, the big trouble is when you log into a machine that
doesn't have your config and don't realize it.  I have the configuration
option set, and I still put --no-chain-reply-to on every command line,
because I've been bitten before.
	The problem with the default of --chain-reply-to is that many
folks consider the resulting email chain rude and stupid.  So the
consequence of not putting it on every command line is occasionally
looking like an idiot.

Joel


-- 

	f/8 and be there.

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: git-send-email

[Jeremy Fitzhardinge]

Peter Zijlstra wrote:
> Hi,
>
> could we change the default of git-send-email to --no-chain-reply-to?
> These incredibly deep mail threads are a nuisance.
>   

And while we're on the **SUBJECT HERE** of git-send-email, would it be 
possible to make it refuse to send when there's placeholders in the file?

    J

Re: git-send-email

[Junio C Hamano]

When git-send-email reads from the mbox, it should expect From:
to be in 2047 (because the input is in Unix mbox format) and
unwrap it before doing the comparison.  Perhaps it is not doing
that.

git-send-email

[Uwe Kleine-König]

Hello,

again my 'ö' is an issue here, sorry Jöhännës :-)

I just tried to send out some patches with git-send-email specifying
--suppress-from.

send-email added me to Cc: anyhow.  Here come the last line of output:

	(mbox) Adding cc: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <ukleinek@informatik.uni-freiburg.de> from line 'From: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <ukleinek@informatik.uni-freiburg.de>'
	OK. Log says:
	Date: Thu, 22 Feb 2007 21:42:49 +0100
	Sendmail: /home/zeisberg/bin/usendmail
	From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
	Subject: [PATCH] Determine system clock from PLL settings
	Cc: =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= <ukleinek@informatik.uni-freiburg.de>
	To: cft.project.parkeon@digi.com

Probably send-email thought =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= being
different from Uwe Kleine-König?  I didn't got a Cc of the introductory
message.

Moreover for each patch the following line was added:

	From: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> - unquoted

which should not be necessary, too.

BTW: Maybe this is related to the problem Russell King has with Perl and
rfc2047:

	http://article.gmane.org/gmane.linux.ports.arm.kernel/30178/

?

Best regards
Uwe

-- 
Uwe Kleine-König

exit vi, lesson II:
: w q ! <CR>

NB: write the current file