From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 1291726 for ; Thu, 22 May 2014 04:49:14 +0000 (UTC) Received: from mail-1y.bbox.fr (mail-1y.bbox.fr [194.158.98.14]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3043F1F8BA for ; Thu, 22 May 2014 04:49:13 +0000 (UTC) Date: Thu, 22 May 2014 06:49:10 +0200 (CEST) Message-Id: <20140522.064910.1233749401586905587.chriscool@tuxfamily.org> To: tiwai@suse.de From: Christian Couder In-Reply-To: References: <20140516030708.GV27822@titan.lakedaemon.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: johan@herland.net, gitster@pobox.com, jason@lakedaemon.net, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TOPIC] Metadata addendum to git commit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , I told Junio and Johan about this discussion, and Junio, as he did not find a good way to subscribe to the list as a newcomer and still send a response to an existing thread, said that I can forward the following. Johan agrees with Junio about this. I don't agree with their opinion about "replace". From: Junio C Hamano : -- >8 -- Takashi Iwai says, in response to what Jason cooper wrote: >> For the stuff flying by me, I've been adding the: >> >> Fixes: <12-char hash>: ('Offending patch subject') >> ... >> I've also been contemplating adding >> >> Coverletter: https://lkml.kernel.org/r/ >> >> for large series where the patch submitter has done a thorough >> writeup >> in the coverletter. > > Yes, this kind of information is helpful for checking patches at > later point, indeed. I tend to think that: * "replace" is too heavy-handed tool to use in general. Nobody sane should publish history full of replacements for public consumption, especially if that is done merely to help bisection. * "notes" is very handy and may be an efficient mechanism to add information after the fact to existing commits, but merging two or more lines of notes histories together is cumbersome. A good way forward to solve Iwai-san's original issue might be * Establish the "Fixes:" mentioned above as a standard practice. Polishing Christian's interpret-trailers tool might be a good way to encourage developers to do so. * Have an easy way for developers to scan incoming commits for these "Fixes:" footer, and record the reverse mapping locally, so that we can go from a commit whose brokenness is discovered later to the commit that fixes its breakage efficiently. "notes" may be a good mechanism to implement this mapping, and we do not have to worry about sharing the notes trees among developers. * The information is visible with "log --show-notes" if it is stored in local notes. When an earlier commit that was later found to be broken is shown, the note that points at the commit that fixes it will be shown. * Teach "bisect" to also take notice of this information, and temporarily cherry-pick while testing commits with fixes that were discovered later, in a way similar to what was suggested by Jiri Kosina in an earlier message. -- >8 --