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é