On 9 January 2013 00:08, 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).
The standard policy is usually enforced via post-commit code review & lots of yelling or via commit hooks which look for specific indicators and reject the commit if they fail. > 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? this can break git blame. I prefer a manual tool "make fixlint" or the like which does the whitespace fixes. -- Eitan Adler _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
