Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)
- Date: Mon, 06 Mar 2017 15:03:15 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)
Junio C Hamano <gitster@xxxxxxxxx> writes:
> Stefan Beller <sbeller@xxxxxxxxxx> 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.