You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
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:
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.
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. 🚀
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
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
Activity
woile commentedon 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 -Sorcz c --commit-args -SWhat's the industry standard to propagate down args? How do other projects do it?
alecgerona commentedon Aug 13, 2020
Industry standard re: command format or the actual mechanism of propagating it? I think for command format
cz cshould be considered as a seamless replacement forgit commitso it could handle any (or at least the ones we support) flag it has.alecgerona commentedon Aug 14, 2020
What do you think @woile?
woile commentedon 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 usingcz 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-argswill be propagated to thebuildcommand.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
to
but we would lose the ability to detect "mistakes" when passing args. If you make a typo like
changleogyou wouldn't know.I'll keep thinking about it, let's share ideas here!
alecgerona commentedon Aug 15, 2020
Why not parse out every known commitizen-specific command and propagate the rest to
gitand let it handle the issue?Lee-W commentedon 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 commentedon 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 commentedon Aug 30, 2020
I would like to take this issue
alecgerona commentedon Aug 30, 2020
Hi @chencheyu that's cool. Can you post here an implementation example so @woile can confirm as well?
woile commentedon Oct 27, 2020
I've been thinking about this and a common pattern is to use
--which would mean "end of the options" forcz c, the rest could go togit committhe 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:
What do you think?
Lee-W commentedon 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 commentedon 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 commentedon Oct 29, 2020
First time I'm seeing it for sure. I'm not sure it's common knowledge at this point. The point of having
cz cfunction "similarly" togit commitis the appeal to its intuitiveness.woile commentedon 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 writecz 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 commentedon 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 commentedon Nov 19, 2020
Hmm we can just catch everything we specifically want to allow and just go case by case with it.
marier-nico commentedon Jun 18, 2021
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 commentedon 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 commentedon Sep 19, 2021
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 commentedon Apr 28, 2023
Signing has been possible for a while:
https://commitizen-tools.github.io/commitizen/commit/#about
javierguzman commentedon Aug 11, 2023
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 commentedon Aug 20, 2023
Hi @javierguzman , according to the
npxmentioned in your comment, I believe what you're using is the commitizen from JavaScript eco systemjavierguzman commentedon Aug 20, 2023
That's right. Why have you mentioned that? Should I do that differently then?
Lee-W commentedon Aug 21, 2023
Yep, this commitizen is implemented in Python. This is not the commitizen you're looking for. 🙂
javierguzman commentedon Aug 21, 2023
Thanks @Lee-W I did not notice as I came from a Google search. I will ask around the cz-cli repo