Re: Issuing warning when hook does not have execution permission

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2014, 16:52 UTC
Message-ID: <xmqqegwcwhfc.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20140819080002.GB7712@peff.net>

Jeff King <peff@peff.net> writes:

Show 28 quoted lines

> On Tue, Aug 19, 2014 at 04:05:21PM +1000, Babak M wrote:
>
>> I saw that if a hook file is present in .git/hooks and it does not
>> have execution permissions it is silently ignored.
>> 
>> I thought it might be worthwhile issuing a warning such as "Warning:
>> pre-commit hook exists but it cannot be executed due to insufficient
>> permissions".
>> 
>> Not sure if this has been discussed before. I searched the archive but
>> didn't see anything.
>> 
>> Thoughts, suggestions? Is there anything like that already?
>
> Once upon a time we shipped sample hooks with their execute bits turned
> off, and such a warning would have been very bad.
>
> These days we give them a ".sample" extension (because Windows installs
> had trouble with the execute bit :) ), so I think it should be OK in
> theory. Installing a new version of git on top of an old one with "make
> install" does not clean up old files. So somebody who has continuously
> upgraded their git via "make install" to the same directory would have
> the old-style sample files. Under your proposal, they would get a lot of
> warnings.
>
> However, that change came in v1.6.0, just over 6 years ago. We can
> probably discount that (and if it does happen, maybe it is time for that
> someone to clean up the other leftover cruft from past git installs).

The above all sounds very sensible.

We have another code path that looks for an executable, finds one with no execute permission and decides not to execute it, and I wonder if we should use the same criteria to decide to give (or not give) a warning as the one used in the other code path (i.e. looking up "git-foo" executable when the user runs "git foo").