Open emzeat opened 11 months ago
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 :)
Thanks,
This is the flow suggested in the pre-commit issue using a combination of commit-msg
and prepare-commit-msg
hooks:
commit-msg
is rejecting a commit, the related commit-msg-file is backed up to a configurable locationprepare-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 detectedThese 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 :)
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:
gitlint
is configured ascommit-msg
hook viapre-commit
as described at https://jorisroovers.com/gitlint/latest/commit_hooks/#pre-commitgit config --global commit.template ~/.gittemplate
git commit
which opens my configured editor prepopulated with the template and I am free to author my commit messagegitlint
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 violationsgitlint
rejects and git aborts the commit as expectedCase 4b. is now the challenging one because
gitlint
will nicely print all my violations, however once I start a second attempt to commit again viagit 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
ascommit-msg
hook look like that does not expose the problem described above?Thanks for helping me on understanding this :)