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<gitster@xxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html