Junio C Hamano <gitster@xxxxxxxxx> writes: > Maxime Louet <maxime@xxxxxxxxx> 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.
