Jeff King <> writes:

> On Mon, Jun 23, 2014 at 10:52:38AM -0700, Junio C Hamano wrote:
>> > The one thing that does give me pause is that we do not seem to have any
>> > way of accessing mergetag signatures. We should perhaps stop and think
>> > for a second about how we might expose those (and whether it would fit
>> > into the "git-verify-{commit,tag}" paradigm). I am tempted to say that
>> > "git verify-tag" on a commit should verify the mergetag (right now it
>> > would simply be an error). But I haven't though that hard on it.
>> I agree that "verify-commit" that lives next to "verify-tag" is fine
>> and does not have to wait for a unified "verify" that may not even
>> be a good idea, but if we were to verify the mergetags in one of
>> these "verify-$OBJECTTYPE" commands, I would think "verify-commit"
>> should be the one to check them, for the simple reason that they
>> appear in "commit" objects, not in "tag" objects.
> My thinking was the opposite: it is a signature on a tag, but that
> signature happens to be stuffed into a commit object. But I do not have
> a strong feeling either way.

Well, the whole point of storing mergetag inside commit objects is
so that these transient "please pull, here is a tag to prove you
that it is from me" tags do not have to be kept in the history;
hence people who are following along only see commits and not tags.
The signature being sent via a signed tag from the requestor to the
integrator is merely an implementation detail after the mergetag is
recorded and when people would want to verify them.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to