From: Sam Vilain Date: Wed, 14 Sep 2011 20:52:48 GMT Subject: Re: Fwd: [Survey] Signed push Message-ID: <4E711420.9080409@vilain.net> In-Reply-To: <7vobynui8a.fsf@alter.siamese.dyndns.org> [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 linustorvalds@osdl.org "torvalds@osdl.org" 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