[Serious Bug] Git-CZ prevent rebase command to squash commits

[yiakwy]

Typing

git rebase -i ${COMMIT_HASH}

The git-cz hook will be called and prevent to squash commits into one.

Is there anyway to prevent this unwanted behaviour?

[travi]

the prepare-commit-msg hook is not required for use of the cz-cli. you've chosen to launch the cli using that hook. simply removing that hook and following the recommended usage approach will avoid this problem.

the behavior you describe is because of the way git applies hooks. this is not specific to commitizen

[yiakwy]

We have a clang-format binary checker which hooks git by pre-commit script. I checked that only prepare-commit-msg script can work with the hook.

#!/usr/bin/env bash
# prepare-commit-msg
exec < /dev/tty && git-cz --hook && ${ROOT}/../node_modules/validate-commit-msg/lib/cli.js

I have provided options for my groups start from:

npm run git:commit

to execute git-cz. However, since this is not mandatory, many people might escape from the check point and validation process only to submit patches with unwanted or harmful messages.

Everything went fine until I started to squash commits by rebase.

[jjangga0214]

@travi But by not configuring with prepare-commit-msg, people(team members) can make arbitrary commmit messages by carelessness. Of course this can be fixed by peer reviews, but considering using commitizen for a systematic approach, this can be a drawback.

And at least to me, git commit is preferable than npm run commit.

Isn't there a way only to use it when really making a new commit? (not by rebase, --amend, etc)

[travi]

but considering using commitizen for a systematic approach, this can be a drawback

it's worth considering whether actually using commitizen is what you are trying to remind your team members of, or if its really about following your commit convention.

on my team, use of commitizen is up to each developer since it is a helpful tool for formatting the commit message according to the convention automatically, but i don't want to prevent preparing a commit in some other way, as long as the convention is followed. therefore, instead of defining a prepare-commit-msg hook, i define a commit-msg that runs commitlint.

[jjangga0214]

@travi Though the original issue is not solved yet, surely thanks for the recommendation.

[platinumazure]

I'm testing this as a workaround in my prepare-commit-msg hook:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

if [ -z "$2" ]; then
    exec < /dev/tty && npx cz --hook
fi

Use this at your own risk, and make adjustments if needed.

Per the prepare-commit-msg hook docs, the second argument can have these values:

• Empty: No message supplied
• "message": Message was supplied via -m or -F
• "template": Template was supplied via -t or via commit.template git config
• "merge": Commit is a merge commit or .git/MERGE_MSG file exists
• "squash": .git/SQUASH_MSG file exists
• "commit": -c, -C, or --amend was supplied. In this case, the script gets a third argument representing the commit object.

In my case, I want the commitizen hook to run on no message, and I don't want it to run for "commit" cases. I don't expect to encounter the other cases in practice.

[gipo355]

I'm testing this as a workaround in my prepare-commit-msg hook:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

if [ -z "$2" ]; then
    exec < /dev/tty && npx cz --hook
fi

Use this at your own risk, and make adjustments if needed.

Per the prepare-commit-msg hook docs, the second argument can have these values:

* Empty: No message supplied

* "message": Message was supplied via `-m` or `-F`

* "template": Template was supplied via `-t` or via `commit.template` git config

* "merge": Commit is a merge commit or `.git/MERGE_MSG` file exists

* "squash": `.git/SQUASH_MSG` file exists

* "commit": `-c`, `-C`, or `--amend` was supplied. In this case, the script gets a third argument representing the commit object.

In my case, I want the commitizen hook to run on no message, and I don't want it to run for "commit" cases. I don't expect to encounter the other cases in practice.

thank you very much, this solved my issue. rebasing now preserves commit messages