Re: [Ksummit-discuss] [TOPIC] Metadata addendum to git commit

[Takashi Iwai <tiwai@suse.de>]

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/<Message-Id>
> 
> 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/<First Reference Msg-Id>
> 
> 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