Yann Dirson, 17.07.2009: > 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) I don't know either, but funny things often cause trouble. send-email would have to parse the patch to avoid adding its own headers. The easiest solution/workaround is that the user should know, whether he does the threading with format-patch or send-email. This is error, of course. See also this recent thread about the same: http://thread.gmane.org/gmane.comp.version-control.git/122554/focus=122584 > - even when --no-thread is specified, and format-patch was run with > --no-thread as well, it still adds In-Reply-To and References headers, > and I must say I do not see what in the code causes this behaviour. This is caused by a bug fixed in commit 5e9758e29 (send-email: fix non-threaded mails, 2009-06-12). Try using "git send-email --no-thread --no-chain-reply" and it may work again. You should use an up-to-date git, when searching for bugs. Markus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html