Add --commit-args command line option to cz commit
Given cz commit wraps git commit, it would be great to be able to pass arbitrary args to the underlying git commit. This is a common pattern, for example, pip-tools' pip-compile has a --pip-args option.
Specifically, I need to be able to pass --no-verify to some commits to occasionally brute force supress hooks but I think you can just allow the user to pass a string of arbitrary --commit-args to cz commit which you then pass through to git commit.
I am interesting to implementing this feature.
But some of git arguments might conflict with cz arguments?
For example, cz c --commit-args -m foo should be invalid because the commit message will be generated by cz?
I am not sure how to process these cases. Just ignore them or print a warning?
It seems similar to this discussion: https://github.com/commitizen-tools/commitizen/issues/248
Which of all the proposed methods would be best? Alternatively we can manually add one by one as they are required (which might not be the best)
@Woile I read the discussion of #248 and I think -- is a good idea.
About handling invalid arguments, I come up with two approach:
- Directly pass all arguments after
--togit commitand letgithandle them. Leave the responsibility of giving correct args to the user. But there are so many edge cases might brakecz's behavior, which affects the UX. - Add a whitelist to filter which argument can use. For example,
-S/--gpg-sign,-s/--signoff,-n/--no-verify. At least I saw issues which discuss about these features. But this is less flexible if the whitelist is hard-coded in source.
I like the first solution a bit more. @Woile what do you think?
Hi all, thanks for the consideration on this ticket. Really keen for this - is anyone picking it up?
@adamcunnington-mlg AFAIK, no one is picking it. Feel free to create a PR if you're interested in it. Thanks!
I've not had chance to pick this up but would really love this
What if we have an exclude list?
On Thu, 7 Apr 2022, 15:24 Bogay, @.***> wrote:
@Woile https://github.com/Woile I read the discussion of #248 https://github.com/commitizen-tools/commitizen/issues/248 and I think -- is a good idea. About handing invalid arguments, I come up with two approach:
- Directly pass all arguments after -- to git commit and let git handle them. Leave the responsibility of giving correct args to the user. But there are so many edge cases might brake cz's behavior, which affects the UX.
- Add a whitelist to filter which argument can use. For example, -S/--gpg-sign, -s/--signoff, -n/--no-verify. At least I saw issues which discuss about these features. But this is less flexible if the whitelist is hard-coded in source.
— Reply to this email directly, view it on GitHub https://github.com/commitizen-tools/commitizen/issues/451#issuecomment-1092067170, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATXJWFGD2BUCGK4ER5QN53VD4R4ZANCNFSM5HNO5DRA . You are receiving this because you were mentioned.Message ID: @.***>
Is anybody working on this?
AFAIK, there's no one working on it. Feel free to take it :)
@Lee-W did anyone review @SCrocky's MR?
Hi @adamcunnington-mlg, I just took a look. The idea is great. But we still need some test and doc
@Lee-W I've added tests on the raises.
I wanted to add a test on successfully passing the extra arguments to the git.commit call, but I'm having a hard time mocking the commands.commit.Commit.__call__ in a way that will allow me to test the arguments property.
As for documentation, I can spare the time to add it. Did you have anything in mind?
Added some simple documentation for the syntax in docs/commit.md
Modifications done, branch rebased, ready for next round