[Ksummit-discuss] [TOPIC] Metadata addendum to git commit
Takashi Iwai
tiwai at suse.de
Fri May 16 09:33:52 UTC 2014
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
More information about the Ksummit-discuss
mailing list