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 3AB7326 for ; Thu, 22 May 2014 05:58:26 +0000 (UTC) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5EB581FA42 for ; Thu, 22 May 2014 05:58:25 +0000 (UTC) Date: Thu, 22 May 2014 07:58:22 +0200 Message-ID: From: Takashi Iwai To: Christian Couder In-Reply-To: <20140522.064910.1233749401586905587.chriscool@tuxfamily.org> References: <20140516030708.GV27822@titan.lakedaemon.net> <20140522.064910.1233749401586905587.chriscool@tuxfamily.org> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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: , At Thu, 22 May 2014 06:49:10 +0200 (CEST), Christian Couder wrote: > > > 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. Do you mean that it's cumbersome from technical/performance viewpoint, or about the appearance of actual text outputs? > 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. These sound like a good plan, indeed. But, one missing, and maybe often happening thing is: people forget to tag at the right time. In the scenario above, if a maintainer forgets to add Fixes: tag in the fix commit, it's all gone? thanks, Takashi