Skip to content
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

Closed
alecgerona opened this issue Aug 13, 2020 · 25 comments
Closed

[Feature Request] Allow commit signing #248

alecgerona opened this issue Aug 13, 2020 · 25 comments
Labels
type: feature A new enhacement proposal

Comments

@alecgerona
Copy link
Contributor

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.

@alecgerona alecgerona added the type: feature A new enhacement proposal label Aug 13, 2020
@woile
Copy link
Member

woile commented Aug 13, 2020

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?

@alecgerona
Copy link
Contributor Author

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.

@alecgerona
Copy link
Contributor Author

What do you think @woile?

@woile
Copy link
Member

woile commented Aug 14, 2020

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!

@alecgerona
Copy link
Contributor Author

alecgerona commented Aug 15, 2020

Why not parse out every known commitizen-specific command and propagate the rest to git and let it handle the issue?

@Lee-W
Copy link
Member

Lee-W commented Aug 16, 2020

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

@woile
Copy link
Member

woile commented Aug 16, 2020

I'd like to see an implementation, I don't understand how would you parse the other args in your example 🤔

@chencheyu
Copy link

I would like to take this issue

@alecgerona
Copy link
Contributor Author

Hi @chencheyu that's cool. Can you post here an implementation example so @woile can confirm as well?

@woile
Copy link
Member

woile commented Oct 27, 2020

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?

@Lee-W
Copy link
Member

Lee-W commented Oct 28, 2020

I think it a great idea. But one of the problems we'll encounter is whether decli/argparse supports this kind of parsing.

@Lee-W
Copy link
Member

Lee-W commented Oct 28, 2020

The methods in this discussion look promising.
https://stackoverflow.com/questions/25864774/how-to-read-the-remaining-of-a-command-line-with-argparse

@alecgerona
Copy link
Contributor Author

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.

@woile
Copy link
Member

woile commented Nov 11, 2020

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?

@Lee-W
Copy link
Member

Lee-W commented Nov 12, 2020

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 --

@alecgerona
Copy link
Contributor Author

Hmm we can just catch everything we specifically want to allow and just go case by case with it.

@marier-nico
Copy link

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. 🚀

@rnc
Copy link

rnc commented Sep 17, 2021

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? )

@Lee-W
Copy link
Member

Lee-W commented Sep 19, 2021

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

@woile
Copy link
Member

woile commented Apr 28, 2023

Signing has been possible for a while:

https://commitizen-tools.github.io/commitizen/commit/#about

@woile woile closed this as completed Apr 28, 2023
@javierguzman
Copy link

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

@Lee-W
Copy link
Member

Lee-W commented Aug 20, 2023

Hi @javierguzman , according to the npx mentioned in your comment, I believe what you're using is the commitizen from JavaScript eco system

@javierguzman
Copy link

Hi @javierguzman , according to the npx mentioned 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?

@Lee-W
Copy link
Member

Lee-W commented Aug 21, 2023

Hi @javierguzman , according to the npx mentioned 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?

Yep, this commitizen is implemented in Python. This is not the commitizen you're looking for. 🙂

@javierguzman
Copy link

Thanks @Lee-W I did not notice as I came from a Google search. I will ask around the cz-cli repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature A new enhacement proposal
Projects
None yet
Development

No branches or pull requests

7 participants