[Bitcoin-development] PSA: Please sign your git commits
chris at beams.io
Mon Jun 9 15:34:18 UTC 2014
An update on this topic:
With the release of Git 2.0, automatic commit signing is now possible with the 'commit.gpgsign' configuration option . 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
$ echo '' >> README.md; time git commit -am"Test commit speed" --gpg-sign
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 .
On May 23, 2014, at 12:23 PM, Wladimir <laanwj at gmail.com> wrote:
> On Wed, May 21, 2014 at 7:10 PM, Wladimir <laanwj at gmail.com> wrote:
>> Hello Chris,
>> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris at 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 ? Note
>>> especially the reference therein to Linus' original negative opinion on
>>> signed commits .
>> 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
> I'll update the document and put it in the repository.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the bitcoin-dev