Re: [PATCH] commit: teach --gpg-sign option

Junio C Hamano venit, vidit, dixit 10.10.2011 00:27:

Michael J Gruber [off-list ref] writes:

quoted

BTW: commit --amend --gpg-sign strips an existing signature rather than
adding one. We might want the user to have a say here.

I think it deserves a separate command (commit --add-gpg-sign) that is
used _only_ to add an additional signature by another person without
affecting anything else in the commit (i.e. the tree, the parents and the
author and committership information) from the viewpoint of the workflow,

Agreed, as I asked "the user to have a say".

Obviously that "add-signature" mode needs to be aware of the existing
signature. It is a deliberate design decision to strip existing signature
when anything in the commit changes, which is the norm for --amend.

What norm? --amend keeps some header fields and discards others. In
fact, signing a commit "without changing it" (i.e. keeping tree, parents
etc., alias "--amend -C HEAD") should be the normal use case for signing
the tip of an existing branch. I mean, I have no problems adding to this:

git help fixup
`git fixup' is aliased to `commit --amend -C HEAD'

But what is the best default for the workflows that we encourage (commit
early, ...)? You answer a pull-request which happens to be a
fast-forward, sign the tip and suddenly you've taken over ownership (and
changed dates)??? Signing a commit should not do this.

Michael