An update on this topic:

With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option [1]. This means that interactively rebased or cherry-picked commits are also re-signed on the fly. The absence of this ability in prior versions of Git meant that signing every commit wasn't a practical policy for anyone using rebase as a regular part of their local development workflow. Now it can be.

Merging also works as expected with this feature turned on.

One caveat I've identified thus far is a negative impact on speed when a large number of commits are involved. Any time you're signing a commit, you're interacting with the gpg-agent daemon, and this is roughly an order of magnitude slower than signing without committing.

Speed without signing:

    $ echo '' >> README.md; time git commit -am"Test commit speed" --no-gpg-sign
    [...]
    real    0m0.031s

and with:

    $ echo '' >> README.md; time git commit -am"Test commit speed" --gpg-sign
    [...]
    real    0m0.360s

For a single commit, this slowdown is negligible as it is still well below sub-second. However, if one were rebasing a local development branch with dozens of commits, you can see how the time would quickly add up.

Personally, I think that in practice I'll be willing to deal with with a few seconds' wait on those relatively rare occasions, and therefore I'm going to keep auto-signing enabled for now [2].

- Chris

[1]: http://article.gmane.org/gmane.comp.version-control.git/250341
[2]: https://github.com/cbeams/dotfiles/commit/d7da74

On May 23, 2014, at 12:23 PM, Wladimir <laanwj@gmail.com> wrote:

> On Wed, May 21, 2014 at 7:10 PM, Wladimir <laanwj@gmail.com> wrote:
>> Hello Chris,
>> 
>> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
>>> I'm personally happy to comply with this for any future commits, but wonder
>>> if you've considered the arguments against commit signing [1]? Note
>>> especially the reference therein to Linus' original negative opinion on
>>> signed commits [2].
>> 
>> Yes, I've read it. But would his alternative, signing tags, really
>> help us more here? How would that work? How would we have to structure
>> the process?
> 
> I think a compromise - that is similar to signing tags but would still
> work with the github process, and leaves a trail after merge - would
> be: if you submit a stack of commits, only sign the most recent one.
> 
> As each commit contains the cryptographic hash of the previous commit,
> which in turns contains the hash of that before it up to the root
> commit, signing every commit if you have multiple in a row is
> redundant.
> 
> I'll update the document and put it in the repository.
> 
> Wladimir