How do you --amend? about cz-cli HOT 14 CLOSED

Is it possible to have the commitizen dialogue load when using git cz --amend?

from cz-cli.

And surprisingly, giz-cz -a does work...

from cz-cli.

Hi @sebastienbarre. Good question. This is unfortunately a bug.

I looked at it quickly and it seems that the editor that opens when using --amend wants to take the context of the cli. Commitizen will not give up the context due to the way commitizen interacts with git using gulp-git so you get this error. We could implement a really dirty solution that looks for --amend in the string I'm not sure that we want to go that route.

Git-gulp uses require('child_process').exec;

I'd love to be able to use require('child_process').spawn; but, I could not figure out how to both wrap the output and provide useful errors and also allow for certain arguments to take over the cli session.

I've looking more into my options here: https://nodejs.org/api/child_process.html#child_process_child_process_spawnsync_command_args_options

If anyone else has experience with this I'd love some recommendations.

from cz-cli.

Thanks for the quick answer @jimthedev. It puzzled me as well, src\app.js seemed to have provision for it, making it look like it was indeed supported:

  // Pass through any additional arguments that would normally
  // go to git.
  var gitArgs = process.argv.slice(2, process.argv.length);

That left me wondering which Git arguments were indeed supported. A mystery. It would be a nice feature indeed, but with that being said, I can just do a git --amend and edit manually. What I like about commitzen is that it provides the structure; as long as I have the type, scope, and message all laid out in the original message, I can write over each parts.

What I'm trying to do, however, is cleanup a small project. I want to rewrite the history to comply with conventional-changelog (the project has not been forked by others). The plan was to do a git rebase -i HEAD~30, Git would rewind me back to the last commit in the list, and drop me on the command line with something like Stopped at f7f3f6d... You can amend the commit now, with git commit --amend. Once you’re satisfied with your changes, run git rebase --continue. Something you are familiar with I'm sure. But instead of git commit --amend I want to use git-cz --amend of course, on all the 30 commits or so.

from cz-cli.

Gosh, this is why I love open source. So many interesting use cases. I am
out of town this weekend and am giving a talk next weekend so next week
will be a rough week as I prep but I'll try to look into how I could manage
the cli context better. It probably would have to be part of 2.0 which
would be over a month out. Thanks for outlining your use case.
On Thu, Sep 24, 2015 at 7:14 PM Sébastien Barré [email protected]
wrote:

Thanks for the quick answer @jimthedev https://github.com/jimthedev. It
puzzled me as well, src\app.js seemed to have provision for it, making it
look like it was indeed supported:

// Pass through any additional arguments that would normally
// go to git.
var gitArgs = process.argv.slice(2, process.argv.length);

That left me wondering which Git arguments were indeed supported. A
mystery. It would be a nice feature indeed, but with that being said, I can
just do a git --amend and edit manually. What I like about commitzen is
that it provides the structure; as long as I have the type, scope, and
message all laid out in the original message, I can write over each parts.

What I'm trying to do, however, is cleanup a small project. I want to
rewrite the history to comply with conventional-changelog (the project has
not been forked by others). The plan was to do a git rebase -i HEAD~30,
Git would rewind me back to the last commit in the list, and drop me on the
command line with something like Stopped at f7f3f6d... You can amend the
commit now, with git commit --amend. Once you’re satisfied with your
changes, run git rebase --continue. Something you are familiar with I'm
sure. But instead of git commit --amend I want to use git-cz --amend of
course, on all the 30 commits or so.

—
Reply to this email directly or view it on GitHub
#12 (comment).

from cz-cli.

Got it. Thanks for being open to the idea.

from cz-cli.

Commitizen is designed to pass any git parameters through to git. This is why git-cz -a works. The problem is that since --amend opens an editor, we're no longer just simply dealing with cli parameters, but have to think about how we create or wrap processes.

from cz-cli.

Thanks @jimthedev ; so this might sound like a crazy idea, but what about intercepting --amend and removing it from the parameters, then use git to query the last commit message, parse it, and pre-populate each of the questions git-cz asks (i.e. the scope, message, description, etc. would be pre-entered, for the user to amend/modify). Now that would be magical :)

from cz-cli.

@sebastienbarre Ooo. I love that idea. The question is, what to do when parsing fails. Care to venture a PR :D

from cz-cli.

@sebastienbarre I was thinking about this a bit more. Specifically I was thinking about your idea of greping the git log. Turns out the tough part would not be getting the previous commit, but rather parsing it into fields. We could defer that functionality to the adapters.

In commitizen's current architecture, the adapters do exactly two things:

1. capture user input
2. output a string back to commitizen-cli

This would need to change if we implemented your feature. Specifically adapters would need to implement a method, say "amend" that re-runs their user input grabbing with certain fields pre-populated. In the current version, the cli doesn't care how adapters get input, as long as they return a template string. In this new scenario, we'd leave it up to the adapters to do more work in order to provide this functionality. I'm going to tentatively add this to 2.1.0 but it might get move around a bit depending on new bugs introduced in 2.0.

from cz-cli.

I agree with you, I think the adapters would have to do some work here.

Funny enough, I was thinking about this issue again this weekend, and decided it wasn't worth the effort rewriting the whole commit history.

What has bitten me a lot as of late though, is going through the whole set of questions, only to end up having to repeat the process again because I forgot to stage files. My muscle memory has always been git -a -m ..., and now that I'm trying to use git-cz, I often forget to issue git -A beforehand. This means I have to stage files, re-run git-cz, and copy/paste the answers from my previous try.

So here is what I think could be useful. And this should probably be handled by the adapters.

When git-cz is invoked:

• open a temporary file (say, JSON),
• each time the user answers a question (be it type, scope, subject, body, etc), append it to the temporary file,
• if the commit succeeds, delete that temporary file.

The next time git-cz is invoked:

• check if there is a temporary file,
• each time the user is prompted a question (be it type, scope, subject, body, etc), pre-populate the answer from the temporary file,
• if the commit succeeds, delete that temporary file.

This would address two things:

• if I forget to stage my files, the commit will fail, but I can just git -A, then git-cz again, and not have to enter all my answers again (I can press [Enter] a few times to accept all my previous choices).
• if I quit / Control+C before the last answer because I realize I forgot to do something (say, bump a version, fix some code), I can still re-run git-cz and find my previous answers.

Just an idea.

from cz-cli.

Totally. In fact, there is an issue about what you mentioned here.

Obviously in Kent's proposed solution we would just not run the prompter and return an error immediately if there are no files staged. It is a simpler solution but should be pretty easy to implement vs the tmp file solution. Thoughts?

from cz-cli.

Oh yes, duh, I should have looked at the other issues, sorry.

from cz-cli.

No worries. :D

Ok, so, I am thinking I'll keep this open for now and we can re-evaluate once 2.0 drops.

from cz-cli.