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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Oct 10, 2011, 06:33 UTC
Message-ID: <4E92919F.2030007@drmicha.warpmail.net>
In-Reply-To: <7v4nzhrebp.fsf@alter.siamese.dyndns.org>

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

Show 9 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> 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