tag:blogger.com,1999:blog-632023420616344756.post8512240022828106967..comments2024-02-03T12:35:11.129-08:00Comments on Git Blame: Helping the kernel workflow_http://www.blogger.com/profile/04508668132209394366noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-632023420616344756.post-38461028169693646672011-11-08T19:31:47.906-08:002011-11-08T19:31:47.906-08:00That was an alternative we have discussed on the l...That was an alternative we have discussed on the list. Store GPG signature for the commit ("push certificate") somewhere in notes tree and push that out, certifying that the commit indeed came from the pusher, but that would:<br /><br />- require upstreams to fetch (and possibly suffer from merge conflicts in notes tree) push certificate whenever they pull from their lieutenants; and<br /><br />- require downstreams to also fetch the notes tree for "push certificates" (especially when the central repository is shared among multiple people) before adding their own signature and then push it back (and possiblly suffer from "non-fast-forward" in notes tree).<br /><br />both of which are downsides coming from "notes" being not a very good match for what these signatures are trying to achieve.<br /><br />The thing is, the "notes" mechanism is designed to keep track of history of changes made to notes attached to commits, but for the signature application, we do not care about the order that signatures came to two separate commits. "Non-fast-forward" conflicts while pushing, or having to fetch and merge before adding one's own signature, are unwanted burden imposed only by choosing to use "notes" for storing and conveying the signature.<br /><br />Also the "notes" approach would end up mixing "push certificates" for different branches into a single "notes" tree.<br /><br />We just want "a bag of annotations that are attached to commits that matter". Fetch only signatures that pertain to the commits that are fetched, and no other. Use of signed tags (that auto-follows the commits upon fetching) is one way to achieve that. Storing the signatures in commit objects that matter (i.e. signed commits store the signature for themselves, and mergetag store the signature of the parent commit that is merged) is another way. Signature stored in notes tree does not behave that way, and not appropriate for our purpose.Gitsterhttps://www.blogger.com/profile/03314622583641323356noreply@blogger.comtag:blogger.com,1999:blog-632023420616344756.post-84237615003813426872011-11-08T09:57:04.359-08:002011-11-08T09:57:04.359-08:00I've thought that using a git-notes like mecha...I've thought that using a git-notes like mechanism to provide post-hoc commit signatures would work well. You'd want to use a different ref stream (and not clog up notes) and have a way of automatically pulling signature refs along with the branch.Aaron Brooksnoreply@blogger.com