Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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. -- 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