-
-
Notifications
You must be signed in to change notification settings - Fork 266
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
Feat 451 add commit args #621
Feat 451 add commit args #621
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for late reviewing. The overall idea looks good to me! But we'll need doc and unit test for this one. After this is merged, I think we can have one branch removing the original signoff and send that PR to v3
branch
Sounds good, I'll get on the tests next. |
Any update on this? We'd appreciate having the tests and rebasing 🙏🏻 |
I have some time this weekend. I'll try to finish it then. |
600f96a
to
75c9f56
Compare
Done rebasing, added both tests and doc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thrilled about this wonderful feature! I was able to spare some time to examine it. I have just provided a few comments and suggestions.
commitizen/commands/commit.py
Outdated
@@ -91,7 +91,11 @@ def __call__(self): | |||
signoff: bool = self.arguments.get("signoff") | |||
|
|||
if signoff: | |||
out.warn("signoff mechanic is deprecated, please use `cz commit -- -s` instead.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@woile Do you think we should add a list somewhere so we won't forget to deprecate stuff in the next release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SCrocky In this implementation, if we're using the original signoff
feature, we won't be able to use extra_cli_args.
. Should we implement it as something like the following? (the warning is still needed)
extra_cli_args = ""
if signoff:
extra_cli_args = "-s "
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see it. Thanks for that.
Would this work for you?
if signoff:
out.warn("signoff mechanic is deprecated, please use `cz commit -- -s` instead.")
extra_args = "-s " + self.arguments.get("extra_cli_args")
else:
extra_args = self.arguments.get("extra_cli_args")
c = git.commit(m, extra_args=extra_args)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might try something like
extra_args = self.arguments.get("extra_cli_args", "")
if signoff:
out.warn("signoff mechanic is deprecated, please use `cz commit -- -s` instead.")
extra_args += " -s"
c = git.commit(m, extra_args=extra_args)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But one thing I'm thinking is whether we should handle cz commit -s -- -s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested it and doesn't seem to be an issue with the git command:
>>> git commit -s -s -m "test commit"
[master (root-commit) b864659] test commit
1 file changed, 0 insertions(+), 0 deletions(-)
But it is a bit messy. Warning or error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't cause an error, I'm good with either silently passing or warning.
commitizen/commands/commit.py
Outdated
c = git.commit(m, "-s") | ||
|
||
if self.arguments.get("extra_cli_args"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this if-else block? Could we handle the case in git.commit()
when extra_cli_args
is not provided?
docs/commit.md
Outdated
``` | ||
cz commit -commitizen-args -- -git-cli-args | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
``` | |
cz commit -commitizen-args -- -git-cli-args | |
``` | |
```sh | |
cz commit -- <git-cli-args> | |
# e.g., cz commit --dry-run -- -a -S |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep commitizen-args
? It provides clarity IMO.
cz commit <commitizen-args> -- <git-cli-args>
# e.g., cz commit --dry-run -- -a -S
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure 🙂 Looks better 👍
raise InvalidCommandArgumentError( | ||
f"Invalid commitizen arguments were found before -- separator: `{' '.join(unknown_args[:pos])}`. " | ||
) | ||
extra_args = " ".join(unknown_args[1:]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might need to handle the case that the user use --
without actually providing an argument. e.g., cz commit --
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, how should we deal with it?
Warning or error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Warning should be enough in this case 👍
Is this wait something? I think |
3d8d27c
to
0bf5c8a
Compare
I've fixed rebased to master, fixed all the previous issues, added/edited tests and added some documentation. @Lee-W ready for Round 2? |
Codecov ReportAttention:
... and 1 file with indirect coverage changes 📢 Thoughts on this report? Let us know!. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@woile @noirbizarre Might need some time to take a deeper look, but I think most of the parts are good.
commitizen/git.py
Outdated
args: str = "", | ||
extra_args: str = "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible for us to combine these 2? Not sure what's the difference between them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extra_args
are arguments that we just want to pass to git
transparently (like -S
).
Having the extra_args
argument separate helps with testing and clarity.
For example:extra_args
has to start with "--" and contain at least one flag behind it. (e.g. "-- -S"
).
If this is contained within the args
argument, then it becomes a little harder to know whether or not any extra args were passed.
Would it be possible for us to combine these 2?
git.commit
is only called with extra_args
in commands/commit.py __call__
method where it doesn't have any args
.
So technically, if I'm not missing anything, I could just use the args
argument to pass the extra_args.
Not sure what's the difference between them
I'll add a Docstring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So technically, if I'm not missing anything, I could just use the args argument to pass the extra_args.
Yep, I think that's what we should do. Thanks for clarifying!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
… for `cz commit` command Additional edits were made in class `commitizen.commands.Commit` and `commit` func from `commitizen.git` Closes commitizen-tools#451
Signoff dedicated code is no longer necessary & removed #TODO as tests show identical args and extra-args are not an issue.
… commitizen args from git commit cli args
ac3f3d9
to
5159a62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @SCrocky, for your contribution! This really helps a lot. Could you please make it ready for review?
@woile @noirbizarre I'm planning on merging it these days. Please let me know if you want to take a look
No problem! I'm really glad to have finally finished it. 🙏
Is this addressed to me? I'm sorry, I'm not sure what the remaining steps are. Is there anything else I need to do? |
Ah, just found out I can do it as well |
Description
Added extra argument mechanic for
cz commit
command so that all arguments after a--
will be treated as extra args.Example: You can now sign commits with
cz c -- -S
Checklist
./scripts/format
and./scripts/test
locally to ensure this change passes linter check and testSteps to Test This Pull Request
Additional context
This PR should close issue 451