fix(pre-commit-hooks): correct rev-range syntax in commitizen-branch by HankyStyle · Pull Request #1841 · commitizen-tools/commitizen
Description
This PR fixes a regression introduced in #1815 where the commitizen-branch pre-commit hook was incorrectly checking the entire git history instead of just the new commits on the branch.
Related Issue
Fixes #1818
Problem
The previous configuration used space-separated arguments for the revision range:
args: [--rev-range, "$PRE_COMMIT_TO_REF $PRE_COMMIT_FROM_REF"]
When passed to git log, this behavior acts as a union, listing all commits reachable from both references. This caused cz check to validate historical commits that were outside the scope of the current changes.
Why It's Broken
- Missing
..operator: Git range syntax requires..between refs - Wrong order: The refs are in the wrong order (should be FROM..TO, not TO FROM)
Solution
Updated the rev-range argument to use the correct Git range syntax FROM..TO:
args: [--rev-range, "$PRE_COMMIT_FROM_REF..$PRE_COMMIT_TO_REF"]
This ensures that commitizen only checks the commits introduced in the current branch (from FROM up to TO).
Checklist
- I have read the contributing guidelines
Was generative AI tooling used to co-author this PR?
- Yes (please specify the tool below)
Generated-by: Gemini 3 Pro
Code Changes
- Add test cases to all the changes you introduce
- Run
uv run poe alllocally to ensure this change passes linter check and tests - Manually test the changes:
- Verify the feature/bug fix works as expected in real-world scenarios
- Test edge cases and error conditions
- Ensure backward compatibility is maintained
- Document any manual testing steps performed
- Update the documentation for the changes
Expected Behavior
The commitizen-branch pre-commit hook should only validate the specific commits being pushed or merged (the range between FROM_REF and TO_REF).
Steps to Verify This Fix
Quick Setup
### Clone and setup git clone https://github.com/commitizen-tools/commitizen.git cd commitizen python3 -m venv .venv source .venv/bin/activate pip install -e .
Create Test Scenario
# Create a test branch git checkout -b test-issue-1818 # Go back in history git reset --hard HEAD~20 # Add a commit with bad formatting (simulate old history) git commit --allow-empty -m "bad commit message" --no-verify # Add a commit with good formatting (simulate new work) git commit --allow-empty -m "feat: good commit" --no-verify # Check what we have git log --oneline -3
Test the Bug vs Fix
# Set up environment variables (like pre-commit does) export PRE_COMMIT_FROM_REF="HEAD~2" export PRE_COMMIT_TO_REF="HEAD" # Test BUGGY format (in https://github.com/commitizen-tools/commitizen/issues/1818 PR) echo "=== BUGGY format (checks ENTIRE history) ===" cz check --rev-range "$PRE_COMMIT_TO_REF $PRE_COMMIT_FROM_REF" # Result: ❌ Fails and shows HUNDREDS of old commits being checked! # Test FIXED format (after this PR) echo "=== FIXED format (checks only the range) ===" cz check --rev-range "$PRE_COMMIT_FROM_REF..$PRE_COMMIT_TO_REF" # Result: ❌ Fails but only checks 2 commits in the range
Expected Results:
- Buggy format: Checks entire repository history (hundreds of commits)
- Fixed format: Only checks 2 commits in the range (HEAD~2..HEAD)

