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 E8210995 for ; Mon, 19 May 2014 13:30:06 +0000 (UTC) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B4C391F97D for ; Mon, 19 May 2014 13:29:58 +0000 (UTC) Date: Mon, 19 May 2014 15:29:55 +0200 Message-ID: From: Takashi Iwai To: Christian Couder In-Reply-To: <20140518.212315.1001026942354195075.chriscool@tuxfamily.org> References: <20140516030708.GV27822@titan.lakedaemon.net> <20140518.212315.1001026942354195075.chriscool@tuxfamily.org> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 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 Sun, 18 May 2014 21:23:15 +0200 (CEST), Christian Couder wrote: > > From: Takashi Iwai > > > > 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. > > It is possible to use "git notes" or even "git replace" to add > information to existing commits. Yes, I know of git-notes, as already mentioned in the first post. But the problem is that publishing and importing git-notes changes isn't well established for kernel git tree management. And, IIRC, Linus didn't like its usage somehow. Not sure whether it's because of git-notes technical design or its concept... > > (*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. > > Yeah, using "git replace" is more elegant. And there will be hopefully > soon the --edit option that will make it very easy to use git replace. We don't want to change the history at all. A preferred option is just addendum on top of the existing commits, and the way to easily share the change (at best with the normal git pull). If git-replace provides such a good integration, I'd love to see it in our use case. thanks, Takashi