Re: [PATCH 1/1] devel/STYLE: information how to enable standard pre-commit hook

[Tomi Ollila <tomi.ollila@iki.fi>]

On Tue, Mar 26 2013, Jani Nikula <jani@nikula.org> wrote:

> On Sat, 23 Mar 2013, Tomi Ollila <tomi.ollila@iki.fi> wrote:
>> It is easier to enable git standard pre-commit hook, when the
>> operation to do so is presented.
>> ---
>>  devel/STYLE | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/devel/STYLE b/devel/STYLE
>> index 0792ba1..92de42c 100644
>> --- a/devel/STYLE
>> +++ b/devel/STYLE
>> @@ -45,8 +45,9 @@ function (param_type param, param_type param)
>>     - likewise, there is a space following keywords such as if and while
>>     - every binary operator should have space on either side.
>>  
>> -* No trailing whitespace. Please enable the standard pre-commit hook
>> -  in git (or an equivalent hook).
>> +* No trailing whitespace. Please enable the standard pre-commit hook in git
>> +  (or an equivalent hook). The standard pre-commit hook is enabled by simply
>> +  renaming file '.git/hooks/pre-commit.sample' to '.git/hooks/pre-commit' .
>
> <bikeshedding>
>
> Or just refer to http://git-scm.com/book/en/Customizing-Git-Git-Hooks or
> man githooks if you really need to. Older versions of git used to have
> properly named hooks with the executable bit unset...

True, older versions used different convention. I presume minority of
users have such an old version.

Just this minor indirection will make many users skip the activation of
the hook as it requires more effort to find the information; I belong
to this group of people; I prefer super simple instructions :D

> Personally I wouldn't ask anyone to enable the hook because I wouldn't
> enable it in the first place. There's $EDITOR and 'git diff --check' to
> do that kind of thing... When I want to commit I want to commit, warts
> and all, and I don't want a hook to prevent me from doing so!

git commit -n (or --no-verify) will bypass the hooks. I have the hook
enabled (in fact I was surprised that it was) and I don't recall a case
when I had to resort to -n option (or edit the content to make the
commit pass the hook).

> </bikeshedding>

So, my point is that if there is clear-enough way to inform majority
of users how to enable hook users will do it; the hook helps users
to provide more compliant code (and, more importantantly, less review
comments about whitespace problems) andd in case there is need to bypass
the check that is also easy to do -- more documentation about bypassing
check could be added, though (I'll do it if this change get supporters...).

>
> BR,
> Jani.


Tomi