On Tue, Jan 8, 2013 at 11:08 PM, Jeffrey Walton <[email protected]> wrote: > On Tue, Jan 8, 2013 at 9:30 PM, Nico Williams <[email protected]> wrote: >> On Tue, Jan 8, 2013 at 12:06 PM, Jeffrey Walton <[email protected]> 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 -- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
