Junio C Hamano <gits...@pobox.com> writes: > Stefan Beller <sbel...@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.
