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 DDFA92FA for ; Fri, 16 May 2014 09:33:54 +0000 (UTC) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6500C2010F for ; Fri, 16 May 2014 09:33:54 +0000 (UTC) Date: Fri, 16 May 2014 11:33:52 +0200 Message-ID: From: Takashi Iwai To: Jason Cooper In-Reply-To: <20140516030708.GV27822@titan.lakedaemon.net> References: <20140516030708.GV27822@titan.lakedaemon.net> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 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, 15 May 2014 23:07:08 -0400, Jason Cooper wrote: > > Takashi, > > On Tue, May 13, 2014 at 03:25:57PM +0200, Takashi Iwai wrote: > > I think this has been already raised a few times, but I'm still > > dreaming one thing in our git management: having some metadata > > collection / link for each commit. > > > > I don't mean for a thing like post-commit sign-off, but rather for > > tracking the information that has been revealed after commit, e.g. a > > regression the commit causes, the later fix commit, > > For the stuff flying by me, I've been adding the: > > Fixes: <12-char hash>: ('Offending patch subject') > > On patches fixing a regression. It helps the stable team (when Cc > stable is also added) and in your scenario, you could grep the commits > for the result of your bisect. Yeah, that was suggested in the last year's KS, and helps some cases. However, the problem is that people(*1) often notice this too late after the tree has been already published. Also, some information (e.g. bug reports) can come only after commits. (*1) statistics taken from one person :) And, for bisection, we need some reverse mapping for efficiency. It'd take time to look all commit logs from each revlist, especially if the bisection is done for the early history. I tried a hackish way once ago: keeping simple text files named with $SHAID in a separate branch, and refers to it at git log or bisect time. There must be much elegant way, I suppose, though. > > or a bugzilla or > > Sorry, I don't use it. > > > ML link for the further discussion or debugging session. > > We've also been autogenerating a tag: > > Link: https://lkml.kernel.org/r/ > > For all patches that points to the email the patch came from. Not > exactly what you were looking for, but nothing prevents someone from > replying to that thread a year later with a regression report. > > 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. thanks, Takashi