From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [PATCH 1/3] git-format-patch: Make the second and subsequent mails replies to the first Date: Sat, 15 Jul 2006 01:10:47 -0700 Message-ID: <7virlzmgoo.fsf@assigned-by-dhcp.cox.net> References: <20060710162920.GR20191@harddisk-recovery.com> <1152556878.8890.45.camel@josh-work.beaverton.ibm.com> <7vwtal9lu1.fsf@assigned-by-dhcp.cox.net> <1152897407.5177.8.camel@josh-work.beaverton.ibm.com> <7v4pxkoxjp.fsf@assigned-by-dhcp.cox.net> <1152904829.5177.19.camel@josh-work.beaverton.ibm.com> <7vwtagnfsk.fsf@assigned-by-dhcp.cox.net> <20060715074532.GF13776@pasky.or.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org X-From: git-owner@vger.kernel.org Sat Jul 15 10:11:23 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G1fFC-0005Jd-Np for gcvg-git@gmane.org; Sat, 15 Jul 2006 10:11:23 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946001AbWGOILA (ORCPT ); Sat, 15 Jul 2006 04:11:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946008AbWGOIK7 (ORCPT ); Sat, 15 Jul 2006 04:10:59 -0400 Received: from fed1rmmtao01.cox.net ([68.230.241.38]:962 "EHLO fed1rmmtao01.cox.net") by vger.kernel.org with ESMTP id S1946001AbWGOIK7 (ORCPT ); Sat, 15 Jul 2006 04:10:59 -0400 Received: from assigned-by-dhcp.cox.net ([68.4.9.127]) by fed1rmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060715081058.BNFQ22974.fed1rmmtao01.cox.net@assigned-by-dhcp.cox.net>; Sat, 15 Jul 2006 04:10:58 -0400 To: Petr Baudis In-Reply-To: <20060715074532.GF13776@pasky.or.cz> (Petr Baudis's message of "Sat, 15 Jul 2006 09:45:32 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Petr Baudis writes: > Dear diary, on Fri, Jul 14, 2006 at 09:32:27PM CEST, I got a letter > where Junio C Hamano said that... >> Josh Triplett writes: >> >> > ..., but you >> > suggested that you didn't mind having threading as the default. >> >> Did I? ... then that was either a mistake or miscommunication. >> >> I do mind changing the default output. I do not mind threading >> as the default ONLY IF user asks for output with these extra >> headers. > > What's the big deal? It's not like we didn't change those things in the > past if it doesn't horribly break everything and the new behaviour is > clearly more sensible. While I agree to the whole three lines, I do not think adding the Message-Id and In-Reply-To header lines by default is more sensible at all. Adding phoney Message-Id to format-patch output makes some sense only when you are sending messages, and if I recall original "motive" message correctly only with git-imap-send. We do not need this for git-send-email, since it can do its own threading. Although I've already accepted the series to "next", now after you brought up the issue, I started to suspect that it might even make sense not to do this in format-patch but make it a responsibility for MUA-looking commands instead. More importantly, format-patch is used to extract patches into separate files (I do that myself often, and I think Andrew Morten uses it to extract stuff from git-maintained trees). In such a case having phoney Message-Id is simply a waste. Running "head -n X 0*.txt" now needs one or two larger X to view the same information, and fewer patches fit on the screen than before. So the new behaviour, if it were not optional, is clearly less useful for such purpose. It could even be confusing and inviting mistakes. When quoting a change from somebody that was sent in an e-mail to the list, giving its Message-Id is often helpful to others who want to go to the source themselves, but if a file that was generated by format-patch by default carries a phoney Message-Id, it can be mistakenly used in such a quote.