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

[Johan Herland <johan@herland.net>]

On Thu, May 22, 2014 at 8:52 AM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> From: Johan Herland <johan@herland.net>
>> On Thu, May 22, 2014 at 7:58 AM, Takashi Iwai <tiwai@suse.de> wrote:
>>>> From: Junio C Hamano <gitster@pobox.com>:
>>>> 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?
>>
>> Yes, unless you add it (using git-notes) as an annotation to the fix
>> commit, but then you're back to the (perceived) problem of sharing
>> those notes.
>
> By the way, I wonder if it might be possible to have signed "notes" or
> signed "replace"?

Isn't that merely a matter of creating a signed tag pointing at
whatever the corresponding refs/notes/* or refs/replace/* ref is
pointing at?

Of course that creates a new refs/tags/* ref that is separate from
your notes/replace ref. If you also want the refs/notes/* or
refs/replace/* ref to point at the signed tag (and have it
automatically peel through to the tagged object) you might run into
some problems. For notes, I'm not sure if the notes code peels through
tags to find the notes commit/tree object. For replace refs, I guess
it would look like the original object was not replaced by a different
object of the same type, but was instead replaced by a signed tag
object. Not sure how to solve that...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net