This PR basically removes the option to define the MFA arity function, instead it expects all MFA functions to have arity 1.
The reason for that is that git will send dynamic arity for the same hooks depending in the git command arguments you are passing.
For example, for the hook prepare_commit_msg, if I run this command: git commit, git will send 1 argument to the MFA, in that case I would need to set the MFA with arity 1. But, if I run this command git commit -am "some message", then git will send 2 arguments to the MFA.
And since we can't define 2 arities for the same MFA, this breaks the current logic.
Removing the arity option and expecting arity 1 always solves the issue since the MFA will always receive a list of arguments.
So, for the above case, I could implement the MFA function using pattern match for each arity expected like this:
This PR basically removes the option to define the MFA arity function, instead it expects all MFA functions to have arity 1.
The reason for that is that git will send dynamic arity for the same hooks depending in the git command arguments you are passing.
For example, for the hook
prepare_commit_msg
, if I run this command:git commit
, git will send 1 argument to the MFA, in that case I would need to set the MFA with arity 1. But, if I run this commandgit commit -am "some message"
, then git will send 2 arguments to the MFA.And since we can't define 2 arities for the same MFA, this breaks the current logic.
Removing the arity option and expecting arity 1 always solves the issue since the MFA will always receive a list of arguments.
So, for the above case, I could implement the MFA function using pattern match for each arity expected like this:
Or, do something like this if you are only interested in the first argument (like I do):