Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxx/ > > 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.
