Full workflow example for fixing a previously rejected commit message

[emzeat]

While evalulating the use of gitlint I was pretty impressed by the configurability and ease of creating your own linting rules. Thanks a lot for creating and maintaining this tool!

When testing an actual commit workflow noticed that any commit messages rejected due to linting violations will get lost though:

1. gitlint is configured as commit-msg hook via pre-commit as described at https://jorisroovers.com/gitlint/latest/commit_hooks/#pre-commit
2. A commit message template is defined via git config --global commit.template ~/.gittemplate
3. I issue a new commit via git commit which opens my configured editor prepopulated with the template and I am free to author my commit message
4. Upon saving and closing the editor, gitlint will spring to life and check the previously authored commit message against my configured rules
   a. In case there is no vilations, all is good. The commit is completed and done.
   b. In case of linting violations gitlint rejects and git aborts the commit as expected

Case 4b. is now the challenging one because gitlint will nicely print all my violations, however once I start a second attempt to commit again via git commit with the plan to correct my commit message all previously authored content is gone and I see the blank template again.

This problem is also discussed in pre-commit/pre-commit#833 with some suggestions to address this but no production grade solution given.

Before diving deeper into working on a pull request to implement a solution like discussed in the referenced issue, I wanted to check here if am simply missing something? What does a typical workflow with gitlint as commit-msg hook look like that does not expose the problem described above?

Thanks for helping me on understanding this :)

[jorisroovers]

I know this isn't perfect, but the commit-msg hook of gitlint itself does print the commit-msg in full in case of violations. You can then copy-paste it.

I haven't looked into the linked pre-commit ticket yet, will do when I have more time :)

[emzeat]

Thanks,

This is the flow suggested in the pre-commit issue using a combination of commit-msg and prepare-commit-msg hooks:

1. Whenever a linter executed via commit-msg is rejecting a commit, the related commit-msg-file is backed up to a configurable location
2. When the user is doing a second attempt, that backup is restored via prepare-commit-msg hook so that the editor is prepopulated with the previously written (but rejected) commit.

What would you think of adding two flags to gitlint:

• --restore-msg-backup <backup-file> will restore a backup found in location "backup-file" to the location given via the existing --msg-filename and delete the backup
• --maintain-msg-backup <backup-file> will perform a backup of the commit message to "backup-file" in case a linting violation is detected

These two would allow to implement the flow I described above by updating the .pre-commit-hooks.yaml as follows:

- id: gitlint-restore
  name: gitlint-restore
  description: Restores any previously rejected git commit message
  language: python
  additional_dependencies: ["./gitlint-core[trusted-deps]"]
  entry: gitlint
  args: [--restore-msg-backup, ".git/gitlint-backup" --msg-filename]
  stages: [prepare-commit-msg]
- id: gitlint
  name: gitlint
  description: Checks your git commit messages for style.
  language: python
  additional_dependencies: ["./gitlint-core[trusted-deps]"]
  entry: gitlint
  args: [--staged, --maintain-msg-backup, ".git/gitlint-backup" --msg-filename]
  stages: [commit-msg]
- id: gitlint-ci
  name: gitlint
  language: python
  additional_dependencies: ["./gitlint-core[trusted-deps]"]
  entry: gitlint
  always_run: true
  pass_filenames: false
  stages: [manual]

Of course I would also understand if you prefer to keep this separate from gitlint - just asking :)