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

[Takashi Iwai <tiwai@suse.de>]

At Thu, 22 May 2014 06:49:10 +0200 (CEST),
Christian Couder wrote:
> 
> 
> I told Junio and Johan about this discussion, and Junio, as he did not
> find a good way to subscribe to the list as a newcomer and still send
> a response to an existing thread, said that I can forward the
> following.
> 
> Johan agrees with Junio about this. I don't agree with their opinion
> about "replace".
> 
> From: Junio C Hamano <gitster@pobox.com>:
> 
> -- >8 --
> 
> Takashi Iwai says, in response to what Jason cooper wrote:
> 
> >> For the stuff flying by me, I've been adding the:
> >> 
> >> Fixes: <12-char hash>: ('Offending patch subject')
> >> ...
> >> 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.
> 
> I tend to think that:
> 
>  * "replace" is too heavy-handed tool to use in general.  Nobody
>    sane should publish history full of replacements for public
>    consumption, especially if that is done merely to help
>    bisection.
> 
>  * "notes" is very handy and may be an efficient mechanism to add
>    information after the fact to existing commits, but merging two
>    or more lines of notes histories together is cumbersome.

Do you mean that it's cumbersome from technical/performance viewpoint,
or about the appearance of actual text outputs?


> A good way forward to solve Iwai-san's original issue might be
> 
>  * Establish the "Fixes:" mentioned above as a standard practice.
>    Polishing Christian's interpret-trailers tool might be a good way
>    to encourage developers to do so.
> 
>  * Have an easy way for developers to scan incoming commits for
>    these "Fixes:" footer, and record the reverse mapping locally, so
>    that we can go from a commit whose brokenness is discovered later
>    to the commit that fixes its breakage efficiently.  "notes" may
>    be a good mechanism to implement this mapping, and we do not have
>    to worry about sharing the notes trees among developers.
> 
>  * The information is visible with "log --show-notes" if it is
>    stored in local notes.  When an earlier commit that was later
>    found to be broken is shown, the note that points at the commit
>    that fixes it will be shown.
> 
>  * Teach "bisect" to also take notice of this information, and
>    temporarily cherry-pick while testing commits with fixes that
>    were discovered later, in a way similar to what was suggested by
>    Jiri Kosina in an earlier message.

These sound like a good plan, indeed.

But, one missing, and maybe often happening thing is: people forget to
tag at the right time.  In the scenario above, if a maintainer forgets
to add Fixes: tag in the fix commit, it's all gone?


thanks,

Takashi