Re: [PATCH 2/2] Improve doc for format-patch threading options.

> On Mon, Jul 06, 2009 at 10:49:29AM +0200, Markus Heidelberg wrote:
> > Yann Dirson, 06.07.2009:
> > > +++ b/Documentation/git-format-patch.txt
> > > @@ -132,9 +133,15 @@ The optional <style> argument can be either `shallow` or `deep`.
> > >  'shallow' threading makes every mail a reply to the head of the
> > >  series, where the head is chosen from the cover letter, the
> > >  `\--in-reply-to`, and the first patch mail, in this order.  'deep'
> > > -threading makes every mail a reply to the previous one.  If not
> > > -specified, defaults to the 'format.thread' configuration, or `shallow`
> > > -if that is not set.
> > > +threading makes every mail a reply to the previous one.
> > > ++
> > > +The default is --no-thread, unless the 'format.thread' configuration
> > > +is set.  If --thread is specified without a style, it defaults to the
> > > +style specified by 'format.thread' if any, or else `shallow`.
> > > ++
> > > +Beware that the default for 'git send-email' is to do deep threading
> > > +if the emails to be sent have no Message-Id header, which is what
> > > +happens when then are generated by 'git format-patch --no-thread'.
> > 
> > Oh, due to the typo I mentioned in my previous mail, I forgot to really
> > comment.
> > 
> > The last paragraph is misleading. git-send-email always adds headers for
> > deep threading by default, regardless of any existing Message-Id
> > headers.
> > The current wording makes one believe, git-send-email respects existing
> > headers if the patches are created with 'git format-patch --thread'.
> > But that it isn't aware of them is exactly what you want to explain
> > here.
> 
> Indeed I realize that I did not grasp correctly how things are
> supposed to fit together.  Reading the code and experimenting, I see
> that:
> 
> - as you say, send-email completely ignores any pre-existing
> In-Reply-To and References header (it does keep the Message-Id's,
> though)
> 
> - send-email simply adds its own In-Reply-To and References headers.
> That IMHO does not make any sense, and the behaviour of such a thing
> is likely to vary among MUAs (if it even does not violate the
> standards, which I did not check)