How do you --amend? - Githubissues

sebastienbarre commented 9 years ago

How does one use git-cz to amend a commit message? It does not seem to be handling extra arguments.

$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)
nothing to commit, working directory clean
$ git-cz -a --amend
[...]
✗ Commit failed. Did you forget to 'git add' your files?

Thank you

jimthedev commented 9 years ago

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.

sebastienbarre commented 9 years ago

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.

jimthedev commented 9 years ago

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é notifications@github.com 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 https://github.com/commitizen/cz-cli/issues/12#issuecomment-143086464.

sebastienbarre commented 9 years ago

Got it. Thanks for being open to the idea.

sebastienbarre commented 9 years ago

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

jimthedev commented 9 years ago

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.

sebastienbarre commented 9 years ago

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

jimthedev commented 9 years ago

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

jimthedev commented 9 years ago

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

capture user input
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.

sebastienbarre commented 9 years ago

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.

jimthedev commented 9 years ago

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?

sebastienbarre commented 9 years ago

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

jimthedev commented 9 years ago

No worries. :D

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

davidungio commented 8 years ago

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

commitizen / cz-cli

How do you --amend? #12