Subject: Re: Fwd: [Survey] Signed push

From: Sam Vilain <[email-masked]>
Date: Wed, 14 Sep 2011 13:52:48 -0700

[re-send as text-only.  sorry, new system]

On 9/14/11 10:49 AM, Junio C Hamano wrote:
>> The extra line in the pull request is cheap - it's not like we need to
>> >  ration them. The above format, in contrast, requires that the person
>> >  doing the*pull*  have a recent enough git client, otherwise the merge
>> >  commit message will be just horrible.
> In a re-roll patch I've added ";# branch-name" at the end of that line for
> people with older git, but existing git wouldn't allow you to fetch anything
> but refs so you won't risk getting "just horrible" merge message;-)
>

If the system is watertight enough, then you could have verified pushes 
ONLY under some new refspace, like:

refs/forks/forkid/branch

"forkid" is set up when you choose to "follow" someone's pushes.  ie, 
you say something like:

git fork follow [email-masked] 
<http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x17762C4676E21CBB>

"[email-masked]" here representing a PGP key ID search string.  It 
could be instead, "0x17762c4676e21cbb"

And then the "refs/forks/linus/xxx" space gets populated as signed 
pushes are seen on the network (perhaps when fetching from a pull 
request, or perhaps via a service).  A configuration option can be set 
to warn if you are not merging a signed branch.  If the new "pull 
request/push" object is a distinct object type or tag object, then it 
could be the destination of the 'refs/forks/...' ref, and the branch 
desription and hence the default merge message be retrieved from that.

Sam