📅 Original date posted:2014-06-09
📝 Original message: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 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 [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140609/283f34a0/attachment.sig>;
Chris Beams [ARCHIVE] /
npub1vl…69gsv
2023-06-07 15:22:34
in reply to nevent1q…8n0k
Author Public Key
npub1vlgx34nzzqzrqq0uujch65yyzyknuduuqulj24ydlnarhwdhwzlsx69gsvPublished at
2023-06-07 15:22:34Event JSON
{
"id": "ee80a9606b7a33be15b8d64b494173548744e8d60156715fa685073bc8b2b078",
"pubkey": "67d068d66210043001fce4b17d5084112d3e379c073f25548dfcfa3bb9b770bf",
"created_at": 1686151354,
"kind": 1,
"tags": [
[
"e",
"e94ff7a2f696c9f496da00240c94bf1f5b7db0838c7b41f99d1fc9dff3db55d1",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-06-09\n📝 Original message:An update on this topic:\n\nWith 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.\n\nMerging also works as expected with this feature turned on.\n\nOne 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.\n\nSpeed without signing:\n\n $ echo '' \u003e\u003e README.md; time git commit -am\"Test commit speed\" --no-gpg-sign\n [...]\n real 0m0.031s\n\nand with:\n\n $ echo '' \u003e\u003e README.md; time git commit -am\"Test commit speed\" --gpg-sign\n [...]\n real 0m0.360s\n\nFor 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.\n\nPersonally, 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].\n\n- Chris\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/250341\n[2]: https://github.com/cbeams/dotfiles/commit/d7da74\n\nOn May 23, 2014, at 12:23 PM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\n\u003e On Wed, May 21, 2014 at 7:10 PM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e\u003e Hello Chris,\n\u003e\u003e \n\u003e\u003e On Wed, May 21, 2014 at 6:39 PM, Chris Beams \u003cchris at beams.io\u003e wrote:\n\u003e\u003e\u003e I'm personally happy to comply with this for any future commits, but wonder\n\u003e\u003e\u003e if you've considered the arguments against commit signing [1]? Note\n\u003e\u003e\u003e especially the reference therein to Linus' original negative opinion on\n\u003e\u003e\u003e signed commits [2].\n\u003e\u003e \n\u003e\u003e Yes, I've read it. But would his alternative, signing tags, really\n\u003e\u003e help us more here? How would that work? How would we have to structure\n\u003e\u003e the process?\n\u003e \n\u003e I think a compromise - that is similar to signing tags but would still\n\u003e work with the github process, and leaves a trail after merge - would\n\u003e be: if you submit a stack of commits, only sign the most recent one.\n\u003e \n\u003e As each commit contains the cryptographic hash of the previous commit,\n\u003e which in turns contains the hash of that before it up to the root\n\u003e commit, signing every commit if you have multiple in a row is\n\u003e redundant.\n\u003e \n\u003e I'll update the document and put it in the repository.\n\u003e \n\u003e Wladimir\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140609/283f34a0/attachment.sig\u003e",
"sig": "b68882df12e8232133dd46b680eebc4af20575b8069b97a7246d78b083b30b20eaf5a04ee64b7df7e37e7fda39cca7c08e7bf88b23f10925fa7c6c1a4a2a7781"
}