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@xxxxxxxxx> a écrit : > > Réda Housni Alaoui <reda.housnialaoui@xxxxxxxxx> 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.
