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

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> 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'

You are *additionally* saying "-C HEAD" in an non-standard alias. Isn't
that enough indication that a vanila "--amend" is intended to record the
commit based on the updated context in which the new commit is made?
E.g. the authorship of the patch is still the same but committer
information is updated.

> 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.

I personally think a pull that is made in response to a pull-request,
i.e. the upstream merging from lieutenant, especially when the
authenticity of the puller matters, is perfectly fine with --no-ff.

Unlike the sign-less "we together made these history and nobody really
owns the result" (aka "Linus hates --no-ff merge because people do that to
leave a mark by peeing in the snow, without adding anything of value in
the history"), the whole purpose of signing a commit in the scenario you
mentioned is for the puller to leave his mark in the history.