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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Oct 11, 2011, 06:39 UTC
Message-ID: <4E93E4B4.9070901@drmicha.warpmail.net>
In-Reply-To: <7vaa98okwl.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 10.10.2011 18:45:

Show 15 quoted lines

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

I was more referring to leaving "parent" and "tree" headers in place, which is a bit of a screwed comparison (because it relies on an unchanged index).

Show 8 quoted lines

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

Yeah, --no-ff would work. I guess we should find out what our "main customers" need here, since our own patch-based workflow is irrelevant, and either approach works with our "single push authority". Seems --no-ff is an easy solution to multiple sigs.

Show 5 quoted lines

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

diff --git i/Documentation/merge-options.txt
w/Documentation/merge-options.txt
index b613d4e..74d6a05 100644
--- i/Documentation/merge-options.txt
+++ w/Documentation/merge-options.txt
@@ -7,6 +7,13 @@ With --no-commit perform the merge but pretend the merge
 failed and do not autocommit, to give the user a chance to
 inspect and further tweak the merge result before committing.

+--pee::
+--no-pee::
+       This activates `--commit` and `--no-ff` and passes
+       `--gpg-sign` to `commit`.
++
+Use `--no-pee` if you do not want or need to pee.
+
 --ff::
 --no-ff::
        Do not generate a merge commit if the merge resolved as

:)

Michael