From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [git patches] libata updates, GPG signed (but see admin notes) Date: Tue, 01 Nov 2011 09:39:01 +0400 Message-ID: <1320125941.7701.14.camel@dabdike> References: <20111026202235.GA20928@havoc.gtf.org> <1319969101.5215.20.camel@dabdike> <1320049150.8283.19.camel@dabdike> <7vy5w1ow90.fsf@alter.siamese.dyndns.org> <4EAF1F40.3030907@zytor.com> <4EAF2245.90308@zytor.com> <7vzkggok6u.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:36477 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750742Ab1KAFjH (ORCPT ); Tue, 1 Nov 2011 01:39:07 -0400 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Linus Torvalds Cc: Junio C Hamano , "H. Peter Anvin" , git@vger.kernel.org, Jeff Garzik , Andrew Morton , linux-ide@vger.kernel.org, LKML On Mon, 2011-10-31 at 15:52 -0700, Linus Torvalds wrote: > On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano wrote: > > > > So nobody is worried about this (quoting from my earlier message)? > > No, because you haven't been reading what we write. > > The tag is useless. It's not useless to people who want to verify the tree after it's been released by you (say for forensics or something). As Peter said, we can put it in a normally invisible namespace, but having a flag to make it visible allows tools like git describe --contains to tell me which signed tag was used to send a particular commit. > The information *in* the tag is not. But it shouldn't be saved in the > tag (or note, or whatever). Because that's just an annoying place for > it to be, with no upside. > > Save it in the commit we generate. BAM! Useful, readable, permanent, > and independently verifiable. > > And the advantage is that we can make that same mechanism add > "maintainer notes" to the merge message too. Right now some > maintainers write good notes about what the merge will bring in, but > they are basically lost, because git is so good at merging and doesn't > even stop to ask people to edit the merge message. A signed empty commit containing the merge message as a comment also looks fine to me. We'd need extra tooling to say which signed merge corresponds to this patch, but I'd say its workable. The only slightly counter intuitive thing is that for a non-trivial merge, my signed merge description will have to be the next commit below rather than in the actual merge you do (because we can't alter a cryptographically signed commit). James