Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2017, 23:03 UTC
Message-ID: <xmqq8toiypn0.fsf@junio-linux.mtv.corp.google.com>
In-Reply-To: <xmqqshmqm4ur.fsf@junio-linux.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 19 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> What is the difference between signed commits and tags?
>> (Not from a technical perspective, but for the end user)
> ...
>> A signed push can certify that a given payload (consisting
>> of multiple commits on possibly multiple branches) was transmitted
>> to a remote, which can be recorded by the remote as e.g. a proof
>> of work.
> ...
> A signed push is _NOT_ about certifying the objects in the history
> DAG.  It is about certifying the _intent_ of pointing _REFS_ into
> points in the object graph.
> ...
> Historically, "tag -s" came a lot earlier.  When a project for
> whatever reason wants signature for each and every commit so that
> they somehow can feel good, without "commit -s", it would have made
> us unnecessary work to scale tag namespace only because there will
> be tons of pointless tags.  "commit -s" was a remedy for that.

While we are enumerating them, it is worth mentioning the mergetag header of a commit object.

This is added to a (merge) commit object when you merged a signed tag that points at a commit, and the intent is to eliminate the need to _keep_ the ref around that is created only for the purpose of "please pull from me, I tagged and signed the tip of the history I want you to pull" request. From that point of view, you could say it is also reducing the load on refs/tags/ namespace, but more importantly by not requiring the ref around, it allows you to verify that the merge commit merged the correct tag with _only_ the commit object by reproducing the payload of the signed tag that was merged in the commit object in full.