[Ksummit-discuss] [TOPIC] Metadata addendum to git commit
Christian Couder
chriscool at tuxfamily.org
Thu May 22 04:49:10 UTC 2014
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 at 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 --
More information about the Ksummit-discuss
mailing list