Gitmoji -c with husky pre-commit

[codingedgar]

Hello @carloscuesta!

Hi, first of all, amazing lib 💛

Issue:
When I commit and husky pre-commit hook fails it's easy to fix the issue and press arrow up and my single line commit message is there, but with gitmoji -c i have to do it all over again.

I know this is not a bug, but is there a harmonic way to integrate husky with gitmoji -c? (I haven't tried the gitmoji hook, because I have not officially introduced gitmoji to my project, I'm just testing waters with the team)

OS: macOS Big Sur
gitmoji -v: 4.7.0
Node version: 14.17.0

[carloscuesta]

Hey @codingedgar this is a great question 😊

I totally understand your concern, sometimes I also experience this issue too 😂, we built two things into the cli to make this process of "retrying a commit" faster with two options:

1. Pre-fill user-input via arguments
2. Printing the failed command in the error output Print Git command if it failed #681

Option 1, allows you to pre-fill some values that will be applied to the commit, so in case something fails, you can use the arrow up key and have all the inputs filled.

Option 2, prints the git command to the error log, in case you want to copy it and execute again the same commit.

Probably there's a better way to do this, I'm open to suggestions for improving this

Thanks!

[codingedgar]

Thank you for the quick and comprehensive reply 💛

I'll try the 1st approach, which probably is what I'm looking for, I use the 2nd which is not convenient with multi-line (a \n is added in the console when it breaks the sentence at print).

I have some ideas:

1. Execute the commit and see if it finishes without errors before finishing with an option to retry.
2. Add a command to retry using the values from the previous gitmoji (guess it requires saving the log somewhere, hopefully not in the current folder to avoid adding it to the .gitignore).
3. Add a command to create only the title and add it to the clipboard to use a regular git commit with a paste (somehow I thought this is what the cli did, like allowed to make the titles with the proper :emojit: added)

I think all of them have their pros and cons

[codingedgar]

Oh, I just noticed the message at the end with the whole command inline and is copied and pasted nicely, no new lines added, I was copying from the log at the beginning which does add a new line.

Also, I think execa does return child process result, which makes the retry possible.

[carloscuesta]

Not sure If I follow, what do you mean by retry?

If a pre-commit hook fails for some reason, the user will need to perform an action to fix it and then retry the commit again.

We can't implement an automatic retry with execa in the following scenario.

[codingedgar]

Sorry for not specifying,

1 and 2 mean retry manually.

In 1, the terminal waits for user confirmation to retry (by a keystroke y/enter), the user can use another terminal to run the git add ..., and after y/enter gitmoji executes the command with all previously set values.

And in 2, the terminal finishes with an error, saves the title/message in a file, and when the user types something like gitmoji --retry the cli executes the last gitmoji command with all the values from the file.

[carloscuesta]

Hello again!

And in 2, the terminal finishes with an error, saves the title/message in a file, and when the user types something like gitmoji --retry the cli executes the last gitmoji command with all the values from the file.

This option is a great idea 😊

We should save the last full command into a temporary file and then re-execute it with the --retry flag. Not sure if there's another potential approach but maybe we can use conf for that?

https://github.com/sindresorhus/conf

[codingedgar]

that sounds very nice, seems like a perfect candidate.

So the mechanism is saving the current full command with conf, and if you pass gitmoji -r or gitmoji --retry then execute the command saved?

If so, i could try to make a PR with the change if that's ok?

[codingedgar]

after a debate with "maybe using gitmoji -c is prone to learning the wrong thing" I went and ran gitmoji --init and used the hook, it has a much better DX, and thankfully pre-commit is run first, so I guess my answer was that all along.

I think the --retry mechanism is nice, but maybe promoting --init is better, I didn't try it because I didn't understand how it worked actually, it seems gitmoji -c is the go-to way to use the cli, it deff should be -- init.

Maybe explaining the benefits of --init over -commit is worth it,

[carloscuesta]

I see! I think both options are useful but depending your use-case the hook approach might be a better choice.

I will try to update and reflect this on the docs 😊