-
-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Allow commit signing #248
Comments
I think for this the best would be to be able to propagate any extra arg to |
Industry standard re: command format or the actual mechanism of propagating it? I think for command format |
What do you think @woile? |
Yes, I agree, it should just work as a replacement for Implementation wise, just propagating the "extra" commands to the underlying command (git commit), seems to be the simplest: 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 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 |
I like @alecgerona 's idea more haha. We might be able to change it here. 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 🤔 |
I would like to take this issue |
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
the whole For example, kubernetes does something similar to propagate a command:
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. |
First time I'm seeing it for sure. I'm not sure it's common knowledge at this point. The point of having |
It's becoming increasingly popular the 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 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., |
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 |
Could the |
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: |
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 |
That'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 |
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.
The text was updated successfully, but these errors were encountered: