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

[Takashi Iwai]

At Tue, 20 May 2014 08:37:18 +0200 (CEST),
Christian Couder wrote:
> 
> From: Takashi Iwai <tiwai at suse.de>
> 
> > At Sun, 18 May 2014 21:23:15 +0200 (CEST),
> > Christian Couder wrote:
> >> 
> >> From: Takashi Iwai <tiwai at 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...
> 
> Maybe Linus just doesn't want to be bothered with maintaining
> notes/replace refs in his git repos. But these refs could be
> maintained by other people in other repos.

Maybe.  But just a guess at this point.


> >> > (*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.
> 
> What I understood is that you want to be able to bisect on a history
> where many bugs that prevent testing can easily be fixed.

Well, the bisection is just an example where the extra metadata would
help.  It's not the purpose itself.

> 
> Using git replace, it can go like this:
> 
> - a developer learns that some part of the history can be fixed to
>   bisect more easily by applying a patch,
> 
> - the developer recreates a part of the history where the patch has
>   been applied (using git cherry-pick or git rebase -i for example)
> 
> - the developer uses git replace to create a replace ref so that the
>   new part of the history is used instead of the old one
> 
> - the developer pushes this new replace ref to a common repo where
>   replace refs are shared (this pushes the new part of the history
>   too)
> 
> - other developers fetch the replace refs from the common repo before
>   they bisect
> 
> - when these other developers bisect, the new parts of the history are
>   automatically used, so bisecting is faster, easier and maybe safer
>   too
> 
> I think that it is better than when everyone changes the history
> manually by applying patches in the middle of a bisection.

This is nice, but I'm not sure whether it'll work / suit well with a
tree like kernel, which is the results of tons of merges from various
maintainers.  I guess little maintainers would publish the corrected
repo.  I hope my guess is wrong.

> > 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.
> 
> git notes is probably better if what you want is only addendum on top
> of the existing commits. git notes creates notes refs that you can
> easily share.

IMO, it's not that easy to share git notes.  At least, it's not in the
same level as sharing tags.  If it were as easy as tags, I see no
reason to avoid using git-notes.  That said, having a separate refs
that requires the extra non-standard step looks like a big obstacle.


thanks,

Takashi