Re: Fwd: [Survey] Signed push
- From
Sam Vilain <sam@vilain.net>
- Date
- Sep 14, 2011, 20:52 UTC
- 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:
Show 8 quoted lines
>> 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 <http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x17762C4676E21CBB>
"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