Re: Sometimes unable to lock the index during pre-commit hook

From: Réda Housni Alaoui <reda.housnialaoui@gmail.com>
Date: Nov 10, 2019, 09:10 UTC
Message-ID: <CAE0unxxzBpTr1afmKfQm_nJYo5oFOftih+vE+wQbFW809rXdaA@mail.gmail.com>
In-Reply-To: <xmqqpni0jioq.fsf@gitster-ct.c.googlers.com>

Thanks for your answer Junio.

As you probably know, many projects (not only mine) format the code during pre-commit hook.

Could git project consider this widespread usecase? I guess unlocking the index (after https://github.com/git/git/blob/master/builtin/commit.c#L419) before running the hooks is not an option here? Could a new kind of hook be added to cover this usecase? If I am not mistaken, this would be similar to prepare-commit-msg which allows to fail or edit the commit message in place.

Le dim. 10 nov. 2019 à 08:26, Junio C Hamano <gitster@pobox.com> a écrit :

Show 22 quoted lines

>
> Réda Housni Alaoui <reda.housnialaoui@gmail.com> writes:
>
> > Are pre-commit hooks expected to be able to manipulate the index?
>
> Hooks are described in githooks(5) manual pages; we may want to
> clarify what is not allowed, but back when most of the entries were
> written, the stance was that anything that is not explicitly allowed
> there is forbidden.
>
> In general, a pre-<something> hook is a way to inspect (i.e. look
> but not touch) what is proposed to be done and veto it by exiting
> with non-zero.  It is not expected to change the state of the
> repository in any way.
>
> The code does not necessarily enforce it, because it is costly to
> take a snapshot of everything (including the index, the working tree
> files, the files that are untracked, the objects in the object
> database, etc.) before calling a hook and ensure that the hook did
> not touch anything.
>
> Thanks.