On Fri, Jun 13, 2014 at 10:06:10AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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 > commit. > > and more, perhaps? That is certainly the direction I was thinking of when I suggested "git verify". 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? -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html