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

[Christian Couder <chriscool@tuxfamily.org>]

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.

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.

-- >8 --