[Feature Request] Allow commit signing

[alecgerona]

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.

[woile]

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]

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]

What do you think @woile?

[woile]

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]

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

[Lee-W]

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]

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

[chencheyu]

I would like to take this issue

[alecgerona]

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

[woile]

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]

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]

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

[alecgerona]

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]

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?