Re: Verbose commit message diff not showing changes from pre-commit hook

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 25, 2020, 15:31 UTC
Message-ID: <xmqqk0yripca.fsf@gitster.c.googlers.com>
In-Reply-To: <xmqqr1sziqrm.fsf@gitster.c.googlers.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 10 quoted lines

> Maxime Louet <maxime@saumon.io> writes:
>
>> Is this expected behaviour? I find it somehow confusing that the diff
>> in the commit message isn't the actual commit diff.
>
> Since the designed purpose of pre-commit hook is to examine the
> contents to be committed and reject the attempt to commit if there
> is something wrong found, and Git does not expect it to munge the
> contents to be committed, if the hook does so, you would get an
> undefined behaviour.  So anything is totally expected at that point.

Sorry, I have to take this back.

Even before ec84bd00 (git-commit: Refactor creation of log message., 2008-02-05), the code anticipated that pre-commit may touch the index and tried to cope with it.

However, ec84bd00 moved the place where we re-read the on-disk index in the sequence, and updated a message that used to read:

- /* - * Re-read the index as pre-commit hook could have updated it, - * and write it out as a tree. - */

to:

+ /* + * Re-read the index as pre-commit hook could have updated it, + * and write it out as a tree. We must do this before we invoke + * the editor and after we invoke run_status above. + */

Unfortunately there is no mention of the reason why we "must" here. I think the "run_status above" is what prepared the patch in the log message template, so it is quite likely that we deliberately did so to exclude whatever munging pre-commit does to the index from appearing in the patch in the verbose mode. If I have to guess, I think the reason is because pre-commit automation is expected to be some sort of mechanical change and not part of the actual work that the end-user produced, it would become easier to perform the "final review" of "what have I done so far---does everything make sense?" if such "extra" changes are excluded.

So, in short, it is not "undefined", but rather it seems to be a designed behaviour that we are seeing.

Thanks.