git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
René Scharfe <l.s.r@web.de>
Date
Jul 26, 2020, 17:41 UTC
Message-ID
<a8c19b13-3f8c-6602-24dd-ef58af70d702@web.de>
In-Reply-To
<xmqqk0yripca.fsf@gitster.c.googlers.com>
Am 25.07.20 um 17:31 schrieb Junio C Hamano:
Show 6 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
Show 19 quoted lines
> 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.
> +	 */

When I read "refactor" in the title, I assume that the patch in question doesn't change user-visible behavior.

> Unfortunately there is no mention of the reason why we "must" here.
@Paolo: Do you perhaps remember the reason?
Show 9 quoted lines
> 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.

Committers review and sign off changes. Hiding machine-made extra changes from them, that they then implicitly also accept responsibility for sounds questionable to me. The prepare-commit-msg hook might be a place for such filtering. But git commit showing the full extent of changes (incl. those made by the pre-commit hook) would be a better default, wouldn't it?

René
Previous: Junio C HamanoNext: Maxime Louet
Message 4 of 6 in “Verbose commit message diff not showing changes from pre-commit hook”
  1. Maxime LouetJul 25, 2020
  2. Junio C HamanoJul 25, 2020
  3. Junio C HamanoJul 25, 2020
  4. René ScharfeJul 26, 2020
  5. Maxime LouetJul 26, 2020
  6. Paolo BonziniJul 27, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.