On Mon, Mar 6, 2017 at 4:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >>> "tag -s" also has the benefit of being retroactive. You can create >>> commit, think about it for a week and then later tag it. And ask >>> others to also tag the same one. You cannot do so with "commit -s". >> >> ok, so there is *no* advantage of signing a commit over tags? > > Did I say anything that remotely resembles that? Puzzled. Well that was brain having a short circuit. > > If the reason you want to have GPG signature on a commit is not > because you want to mark some meaningful place in the history, but > you are signing each and every ones out of some random reason, and I am looking for these "some random reason"s. If it is e.g. a ISO9001 requirement, I'll happily accept that as such. By signing things, you certify your intent, i.e. by signing a commit, you certify that you intent to create the commit as-is in some repository on some branch (unlike the push certificate that specifies the repo and branch). > there > is no reason why you would want "tag -s" them, so you can see it as > an advantage of "commit -s" over "tag -s", because to such a > project, all commits that are not tagged look the same and there is > no "landmark" value to use "tag -s" for each and every one of them. Okay. They are two different things, but to me they seem to archive the same thing, with a tag having more niceties provided. e.g. when you make a new release, you could just bump the version in the versions file and sign the commit. As the commit is part of the master branch it would not get lost. The formerly mentioned "not polluting the refs/tags namespace" is applicable to mergetags, that are a side tangent to signing the commit vs creating a tag? Now as Jakub mentions that signed commits came before the mergetags were introduced, the existence of signed commits sort of makes sense, as they were there first, but now are superseded by more powerful tools. > It is entirely reasonable to sign a merge commit that merges a > signed tag. They serve two different and unrelated purposes. The signed tag that gets merged certifies the intent of the lieutenant to ask for this specific content to be pulled and integrated, whereas the signing of the commit certifies that the integrator intends to create the merge commit as-is and e.g. resolve the merge conflicts as recorded. Thanks, Stefan