Re: [git patches] libata updates, GPG signed (but see admin notes)

From: James Bottomley <james.bottomley@hansenpartnership.com>
Date: Nov 1, 2011, 05:39 UTC
Message-ID: <1320125941.7701.14.camel@dabdike>
In-Reply-To: <CA+55aFwnVZ-mK3FChvFn778Z-cT107f4v-h0CDmwkP88=Z9aHA@mail.gmail.com>

On Mon, 2011-10-31 at 15:52 -0700, Linus Torvalds wrote:

Show 7 quoted lines

> On Mon, Oct 31, 2011 at 3:44 PM, Junio C Hamano <gitster@pobox.com> 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.

Show 12 quoted lines

> 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