commitizen-tools
[Feature Request] Allow commit signing
Description
Respect git flag -S and/or other related flags for commit signing when using the cli tool.
Possible Solution
Sign commits using the cli tool.
I think for this the best would be to be able to propagate any extra arg to git commit.
Example cz c --extra-args -S or cz c --commit-args -S
What's the industry standard to propagate down args? How do other projects do it?
Industry standard re: command format or the actual mechanism of propagating it? I think for command format cz c should be considered as a seamless replacement for git commit so it could handle any (or at least the ones we support) flag it has.
Yes, I agree, it should just work as a replacement for git commit, you should be able to do everything you do with it using cz c.
My questions was comparing to other cli tools, how they do it. For example, in docker you can run docker run --build-args, and those --build-args will be propagated to the build command.
Implementation wise, just propagating the "extra" commands to the underlying command (git commit), seems to be the simplest: we could make a swap here from
args = parser.parse_args()
to
args, unknown = parser.parse_known_args()
but we would lose the ability to detect "mistakes" when passing args. If you make a typo like changleog you wouldn't know.
I'll keep thinking about it, let's share ideas here!
Why not parse out every known commitizen-specific command and propagate the rest to git and let it handle the issue?
I like @alecgerona 's idea more haha. We might be able to change it here. https://github.com/commitizen-tools/commitizen/blob/master/commitizen/commands/commit.py#L76
We can still output the error from git
I'd like to see an implementation, I don't understand how would you parse the other args in your example :thinking:
Hi @chencheyu that's cool. Can you post here an implementation example so @Woile can confirm as well?
I've been thinking about this and a common pattern is to use -- which would mean "end of the options" for cz c, the rest could go to git commit
cz commit -- -a -m "hello"
the whole -a -m "hello" could be given to git, and it would not require maintenance from us (typehints, code, etc). if there's an error you'd see it in the git output.
For example, kubernetes does something similar to propagate a command:
kubectl exec my-pod -- ls /
What do you think?
I think it a great idea. But one of the problems we'll encounter is whether decli/argparse supports this kind of parsing.
The methods in this discussion look promising. https://stackoverflow.com/questions/25864774/how-to-read-the-remaining-of-a-command-line-with-argparse
First time I'm seeing it for sure. I'm not sure it's common knowledge at this point. The point of having cz c function "similarly" to git commit is the appeal to its intuitiveness.
It's becoming increasingly popular the --. I think it's the right approach. It's a bit of a trade-off.
Instead of git commit -s, you'd write cz c -- -s.
I understand that you'd want it to be propagated directly, but that would mean to manually add every git commit option to our parser, creating the possibility of bugs on commitizen. I don't know many of the flags, and we'd have to catch them with the right types, and we'd be tied to potential new git flags.
Instead, if we propagate them using --, it would be up to the developer to properly send the right git flags.
Any other alternatives?
Not sure whether this will work https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_known_args. But it might still not be able to handle arguments that's too complicate (e.g., --unknown-arg arg-1 arg-2). I second the idea of --
Hmm we can just catch everything we specifically want to allow and just go case by case with it.
Jumping in because I would also love this feature to happen. Personally when I originally started using commitizen, I thought the commit functionality was just purely a wrapper around the existing git command, and I do think that's what would be most intuitive to users in general.
But admittedly I would also be happy with the -- idea. I use an alias for committing anyway, so it's not like it would make a practical difference for me. :rocket:
Could the -- <extra-args> be specified in a configuration file as a default option therebye avoiding having to add it to the command line everytime? (and on that point could the configuration file be project local versus home directory? )
Could the
-- <extra-args>be specified in a configuration file as a default option therebye avoiding having to add it to the command line everytime? (and on that point could the configuration file be project local versus home directory? )
I think that might depend on how this feature is implemented. We can consider this feature when someone has the bandwidth to implement this feature
Signing has been possible for a while:
https://commitizen-tools.github.io/commitizen/commit/#about
I have in my husky "test -t 1 && exec < /dev/tty && npx cz --signoff --hook || true" but commits are still not signed-off. Am I missing something? Thank you in advance and regards
Hi @javierguzman , according to the npx mentioned in your comment, I believe what you're using is the commitizen from JavaScript eco system
Hi @javierguzman , according to the
npxmentioned in your comment, I believe what you're using is the commitizen from JavaScript eco system
That's right. Why have you mentioned that? Should I do that differently then?
Hi @javierguzman , according to the
npxmentioned in your comment, I believe what you're using is the commitizen from JavaScript eco systemThat's right. Why have you mentioned that? Should I do that differently then?
Yep, this commitizen is implemented in Python. This is not the commitizen you're looking for. 🙂
Thanks @Lee-W I did not notice as I came from a Google search. I will ask around the cz-cli repo