On Fri, Jun 13, 2014 at 10:06:10AM -0700, Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes:
> > I realize this isn't really your itch to scratch. It's just that when I
> > see a description like "verify a commit", I wonder what exactly "verify"
> > means.
> I think that is an important point. If a tool only verifies the
> signature of the commit when conceivably other aspect of it could
> also be verified but we cannot decide how or we decide we should not
> dictate one-way-fits-all, using a generic name "verify-commit" or
> "verify" without marking that it is currently only on the signature
> clearly somewhere might close the door to the future.
> git verify <object>::
> Verify whatever we currently deem is appropriate for the
> given type of object.
> git verify --gpg-signature::
> Verify the GPG signature for a signed tag, a signed commit,
> or a merge with signed tags.
> git verify --commit-author <committish>::
> Verify the GPG signer matches the "author " header of the
> and more, perhaps?
That is certainly the direction I was thinking of when I suggested "git
However, I do not think it is too bad a thing to add a verify-commit
that matches verify-tag, as long as they do the exact same thing
(namely, check the gpg signature). We may find it is later obsoleted by
"git verify --gpg-signature", but given that verify-tag is already there
and will remain for compatibility, I don't think we are increasing the
cognitive load too much.
Your middle example above did make me think of one other thing, though.
As you noted, we actually have _three_ signature types:
1. signed tags
2. signed commits
3. merges with embedded mergetag headers
We already have a tool for (1). Michael is adding a tool for (2). How
would one check (3) in a similar way?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html