Re: Git not commiting anything if file created and "git add"ed in pre-commit hook is the only file in the staging area

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> The commit history does not explain why we must do this _after_ invoking
>> run_status, but if the comment is incorrect and we re-read it
>> immediately, then this problem would go away.  I lack the relevant
>> context to determine whether this is appropriate, but if folks think
>> this is advisable, then I can write up a patch this weekend.  It should
>> be relatively trivial.
>
> There's some related discussion of this area in:
>
>   https://lore.kernel.org/git/CADv3qkGq3jA8iXsjhrqfsUX=gW+KOuLyeVgDzmku1tUpsMdvtw@mail.gmail.com/
>
> I don't find it particularly enlightening as to the history, but it does
> point to other people wanting to re-read before run_status().

Ah, OK.  Because we call run_status() to see if there is anything
"committable" is there in the part of the changes that the user
prepared (before hooks futzed with the index), and reject if (for
example) there is nothing to commit, we deliberately refuse the case
where the invoker of "git commit" does *nothing* and the only change
between HEAD and the index to be committed after the hook runs is
what was done by the hook.  IOW, the current behaviour was designed
specifically to handle the case that started this thread.

Interesting.  I think the reasoning makes sense, and having to say
allow-empty, and being able to bypass by saying allow-empty, is a
feature from the point of view of that design.