Fixup / Autosquash commits about conventional-pre-commit HOT 6 CLOSED

@DanielVoogsgerd thank you so much for a thoughtful issue write-up and proposed solution! We're glad the pre-commit hook has been useful.

Your use-case seems really valid, I too love a good git rebase. And I I have literally never heard of or seen usage of the
git commit --fixup-style commits, thank you for enlightening me!

As you noted though, this does take us away from strictly Conventional Commits formatting, something that I would like this hook to stay as close to as possible. So unfortunately I won't be able to accept #5 as-is (more below, please keep reading!)

I want to point out that a git-based workaround for #5 does exist, and that is the --no-verify flag:

Before

$ git commit --fixup HEAD
Conventional Commit......................................................Failed
- hook id: conventional-pre-commit
- exit code: 1

[Commit message] fixup! feat: previous commit message

Your commit message does not follow Conventional Commits formatting
https://www.conventionalcommits.org/

...

After

$ git commit --fixup HEAD --no-verify
[main 25fde30] fixup! feat: previous commit message
 1 file changed, 1 insertion(+), 1 deletion(-)

I tend to use this flag for exactly the use-case that you describe, revising a commit far in the history, purely in a local sense before I clean up the history for a push to remote. I was always doing it the git rebase -i way, and your approach seems like a great addition!

I'm going to leave some more comments directly on #5 because I do like part of that PR and would welcome the change - perhaps to setup your other proposal for #3.

Thank you again!

from conventional-pre-commit.

Thanks for the elaborate response!
I did not know about --no-verify. That solves my problem of not being able to use fixup commits. The only problem I might have with using it is the lack of granularity. It will skip all commit hooks which might not be a good idea as other suppressed commit hooks can then be triggered mid rebase. However a more elegant solution would probably be to make it optional to allow these types of commits. But implementing that might be a bit of a pain considering how the arguments are used for additional commit types.

Lets close this issue for now and see if problems arise from using --no-verify.

from conventional-pre-commit.

As referenced above: I created a PR with a proposed solution.

from conventional-pre-commit.