Junio C Hamano venit, vidit, dixit 10.10.2011 00:27: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html