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 <laa...@gmail.com> wrote:
> On Wed, May 21, 2014 at 7:10 PM, Wladimir <laa...@gmail.com> wrote:
>> Hello Chris,
>>
>> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <ch...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
