On 9/13/11 9:45 AM, Junio C Hamano wrote:

  * You push out your work with "git push -s";

  * "git push" prepares a "push certificate" (it is meant to certify "these
    are the commits I place at the tips of these refs"), which is a human
    and machine readable text file in core, that may look like this:

         Push-Certificate-Version: 0
         Pusher: Junio C Hamano[off-list ref]
         Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
         Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next

    and asks you to GPG sign it. You only unlock your GPG key and the
    command internally runs GPG, just like "tag -s".

  * When "git push" finishes, the receiving end has this record in its
    refs/notes/signed-push notes tree, together with your previous pushes
    (as this is not a shared repository, it will record only your pushes).
    The notes annnotate the commits named on the "Update:" lines above.

If the push certificate also has the previous commit IDs for the changed 
refs, then you actually have an audit log.  Otherwise, it does not 
certify the commit range they pushed.

This is an important prerequisite for a fully distributed, peer to peer 
git.  For this case it would also need something to distinguish which 
repository is to be updated; such as a canonical repository URL (or list 
of URLs), or just a short project name.  A P2P protocol can then know 
projects as (KEYID, projectname).

Sam