According to the pre-commit documentation for adding new hooks the default is not to run hooks when there are no files to be checked and the checkmake hook configuration does not override this, so I am not really sure why this is helping, but it has.

Can you show the output you're seeing when it fails? I've used checkmake at rev c047d51 for many months now without a problem across more than a dozen repos.

it would be good to have a more detailed description here of what exactly fails and how this is fixing it. Especially since there are reports where things are working.

Alternative perspective

the pitch

Conversely to making the need to specify a file (e.g., the path to a makefile) to scan/lint an option, I'd suggest adding an option to search/find obvious makefiles, such as files named "[mM]akefile" or ending with ".make" or with ".makefile" (and of-course accept an optional custom argument for users to specify glob patterns).

TL;DR - some risks

1. Changing to allow omitting the currently required makefile argument would regress the trivial use-case where a zero-length path (e.g., some script variable erroneously expanded to empty-string ""), instead of the required makefile path to a possible false-success.

example (hint for regression testing):

MAKE_FILES=$(git ls-files --exclude-standard -- includes/enable_*.make 2>/dev/null)  # assume the expected matches are not on the current branch (no enabled includes)
checkmake $MAKE_FILES  # currently will fail due to no valid paths
exit $?  # pass the pass/fail to caller

However if made optional the example case would change behavior to no-longer fail just because MAKE_FILES is empty. And, of-course, the bash code can be changed to preemptively check the variable (e.g., test -z $MAKE_FILES || exit 1), but the point is in how that is not necessary with the current implementation.

Thanks for reading this far,
🙇 Hope this helps

@michael-delarue-axomic , as @mrtazz has already requested, could you please describe with some level of detail, what exactly is the problem that this PR is intended to fix?

I. E., please give a precise description of and steps to reproduce the issue.

@michael-delarue-axomic also, the change looks simple enough but I can't really see what behavior changes it introduces.

Could you add example invocations with and without the patch with different results?

rebased on current main branch

rebased on current main branch

The branch update button created a merge commit which makes no sense IMHO.

So I creaded a clean rebase locally and updated the PR.

rebased on current main branch