[Ksummit-discuss] [TOPIC] Metadata addendum to git commit
Takashi Iwai
tiwai at suse.de
Mon May 19 13:29:55 UTC 2014
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...
> > (*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
More information about the Ksummit-discuss
mailing list