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

[Takashi Iwai <tiwai@suse.de>]

At Sun, 18 May 2014 21:23:15 +0200 (CEST),
Christian Couder wrote:
> 
> From: 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.
> 
> 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