Re: [PATCH 2/2] push -s: skeleton

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On Thu, Sep 8, 2011 at 6:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
> A better alternative could be to sign a "push certificate" (for the lack
> of better name) every time you push, asserting that what commits you are
> pushing to update which refs. The basic workflow goes like this:
>
>  1. You push out your work with "git push -s";
>
>  2. "git push", as usual, learns where the remote refs are and which refs
>    are to be updated with this push. It prepares a text file in memory
>    that looks like this using this information:
>
>        Push-Certificate-Version: 1
>        Pusher: Junio C Hamano <gitster@pobox.com> 1315427886 -0700
>        Update: e83c51633... d4e58965f... refs/heads/master
>        Update: 5a144a288... 7931f38a2... refs/heads/next
>
>    An actual push certificate records full 40-char object name, but it is
>    ellided for brevity here.
>
>    The user then is asked to sign this push certificate using GPG. The
>    result is carried to the other side (i.e. receive-pack). In the
>    protocol exchange, this step comes immediately after the sender tells
>    what the result of the push should be, before it sends the pack data.
>
>  3. The receiving end will keep the signed push certificate in core,
>    receives the pack data and unpacks (or stores and runs index-pack)
>    as usual.
>
>  4. A new phase to record the push certificate is introduced in the
>    codepath after the receiving end runs receive_hook(). It is envisioned
>    that this phase:
>
>    a. parses the updated-to object names, and appends the push
>       certificate (still GPG signed) to a note attached to each of the
>       objects that will sit at the tip of the refs;

I recall Gentoo wanted something like this (recording who pushes
what). Pulling Robin in if he has any comments.
-- 
Duy