New `retry_after_failure` config option and `--no-retry` overwrite flag

[crai0]

Description

In order to allow for a streamlined commit-fix-commit cycle when using git hooks or pre-commit, an option to automatically reuse the last commit message if the commit failed should be added.

Possible Solution

• There's a new retry_after_failure config option
• By default, it is set to false
• If it is set to true, cz commit reuses the commit message from the backup file if it is present
• If the backup file is not present, the usual behavior is carried out
• There's a new --no-retry option to overwrite the config (e.g. running cz commit --no-retry behaves as if retry_after_failure were set to false)
• The current retry implementation is improved so that the backup file is written to a path that depends on the current user and git working tree directory. This allows for the usage of --retry when working in multiple repositories simultaneously

Additional context

No response

Additional context

No response

[ahmed2m]

How is this not implemented yet? Feels intuitive to have it and the --retry is not even well-documented, I had to dig up the documentation to find it.

[woile]

This a volunteer's run project, if you think the docs could be better, we would love to hear your feedback or even better, submit a PR with your suggestions so they don't happen to the next person.

In general, we, as the maintainers, have very little capacity available, so PR's for adding this new feature are also welcome

[ahmed2m]

This a volunteer's run project, if you think the docs could be better, we would love to hear your feedback or even better, submit a PR with your suggestions so they don't happen to the next person.

In general, we, as the maintainers, have very little capacity available, so PR's for adding this new feature are also welcome

I understand, I don't take open source for granted, with my original reply I had the intent of saying (this should be popular or have high demand feature that it would be implemented by now, by contributors) not projecting any blame on the maintainers of course.