Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I'd think we'd want to call it on an empty message, e.g. maybe someone > depends on that with empty message = auto-generate a message for me. I tend to agree with you that, especially if we are to keep the "commit-msg hook is allowed to change the message, even though it is a job for other hooks", we should invoke it even on an empty file. > But for those that don't, doesn't the default behavior of "git commit" > catch this in either case, i.e. it wouldn't let it pass without > --allow-empty-message. > > I understood this report as the hook taking the empty message (e.g. the > user using it as a shorthand to abort), and their hook "helpfully" > inserting some "default" message or template. My understanding largely overlaps with yours but with some differences. They do not fall into either of the two camps. Their hook does futz with the message indiscriminately and adds some boilerplate material blindly, even to an empty file. The complaint is "the message is otherwise without any substance, but because the hook blindly added some boilerplate material into the empty original, it appears to be non-empty and fails to trigger the --no-allow-empty-message machinery."
