Improve feedback flow

[jzaefferer]

Currently the commit-msg hook is rather bad at providing feedback. It aborts the commit, dumps the message on the terminal and then leaves it to the user to start over. Something a little more interactive would be nice, like keeping the previous message when attempting to commit again.

Hoping @all3fox might have some ideas what we could do here.

[alisianoi]

Yes, I agree that it is very annoying to loose a (long) carefully crafted commit message simply because it failed one-or-two syntax checks. So it needs a way to persist to next commit.

Well, a wild idea would be "autocorrection" of the more obvious style errors. For example, remove full stops at the end of the subject line and. Or even if some style check failed with an error, then a subsequent template might attempt to correct it for the user (like provide a default scope of the change or attempt to insert a missing newline between subject and body)

But those are all wild. The important thing is to definitely keep the commit message instead of throwing it away. That functionality goes hand-in-hand with a issue 25 message template.

[jzaefferer]

Reusing the previous commit message as a template for the next one, but only if the last attempt failed, sounds interesting. Could still combine that with an actual template, when there is no previous failed attempt.

[alisianoi]

My current thinking is to write a separate prepare-commit-msg hook that checks the contents of the .git/COMMIT_EDITMSG file. If the contents of that file fail the style check, then these contents are reused as a commit message template. If the contents pass (or there is no such file), then use some prepared-in-advance template. This hook will get installed by the already-present logic from install.js

That was for a repo-local install. The global install behaves differently: it just looks at commit history. So there will be no templates at all, they do not make sense.

[jzaefferer]

That sounds good!

[jzaefferer]

@all3fox would still be great to address this. Will you have a chance to implement it?

[alisianoi]

@jzaefferer I will see what I can do on Wednesday 7/12/16

[jzaefferer]

@all3fox would you still be interested in working on this?

[alisianoi]

Sorry to keep feeding you promises. I tried to hack it yesterday-today but did not make much progress.

It is also a month of exams for me now, so I will not be doing it in January anymore, I will get back to it in February.

Here is an actual question for you: in order to reuse the faulty commit message, it has to be saved somewhere. So, the commit-msg hook has to save it somewhere and the prepare-commit-msg hook has to check that place during next commit sequence. Where would you save it?

COMMIT_EDITMSG does not work for that unfortunately. It stores the old commit message, but the next git commit overwrites the contents of that file before triggering the prepare-commit-msg hook.

[jzaefferer]

Could we write a COMMIT_EDITMSG_OLD before exiting with an error code, and look for that the next time?

[jzaefferer]

Fixed by 5fe2074, released as 2.7.8.