[cryptography] openssl on git

Nico Williams nico at cryptonector.com
Wed Jan 9 02:02:33 EST 2013


On Tue, Jan 8, 2013 at 11:08 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams <nico at cryptonector.com> wrote:
>> On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> Would you consider adding a hook to git (assuming it include the ability).
>>>
>>> Have the hook replace tabs with white space. This is necessary because
>>> different editors render tabs in different widths. So white space
>>> makes thing consistent for everyone.
>>
>> Hooks shouldn't modify the commit, just accept or reject.
> Thanks Nico.
>
> Out of curiosity: what does one typically do when there's a standard
> policy to enforce? I [personally] would not reject a check-in for
> whitespace (I would reject for many other reasons, though - such as
> CompSci 101 omissions).

A number of projects I've worked on -particularly Solaris, but not
only- absolutely reject pushes of code (and docs, and tests, and build
goop) that fails style and other tests.  Some even go so far as to
trigger an incremental build to check that all is ok (but rarely is
this done synchronously, and so build failures -> email, possible
backout, ...).

> Perhaps allow the check-in to proceed unmolested, and then have a
> second process run after the commit to perform policy enforcement (for
> example, whitespace or coding style). In this scenario, would the
> second process perform a second commit?

Fast checks should be done synchronously and failure -> push rejection.

Slow checks should be done asynchronously and failure -> nastygram.

Slow check failures can be corrected in either of two ways: backout
(mostly to be avoided, except when nearing releases or build
milestones) or subsequent push to fix the issues.

The more you can check quickly, the better:

 - *style (C style, Java style, JS style, ...)
 - referential integrity / software engineering process (commit
references bug report, bug report is in correct state, if the bug
report indicates that the fix should have docs impact then check that
docs are updated, check that codereview has happened and the code has
been signed off, or perhaps that code reviewers are listed, ...)

Slower checks:

 - build
 - static bug analysis (including, for languages that need it, *lint)
 - tests

Do all this, and your life will be easier.  Every hour you put into
writing checkers of this sort will pay for itself many times over for
any sufficiently large project.

Some such checkers can easily be found by searching around.  The
Solaris gate checks are, IIRC, in OpenSolaris and derivatives, for
example, but I've seen others.

Nico
--



More information about the cryptography mailing list