fix(pre-commit-hooks): correct rev-range syntax in commitizen-branch

[HankyStyle]

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

1. Missing .. operator: Git range syntax requires .. between refs
2. 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 all locally 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)

[bearomorphism]

Great! Thanks for detailed analysis and explanation.

[pgrenaud]

I still don't think this would work. But let me just double check real quick on my end before I start babbling nonsense.

[pgrenaud]

Ok, yes, this does seems to work on my end as well.

[bearomorphism]

@pgrenaud thanks for verifying the change!

[bearomorphism]

Looks good to me but I haven't validate it yet

[noirbizarre]

Good to me, fix the the current issue.

BUT, for another PR, I realize that those variables are only available in the pre-push and post-checkout stages (cf. https://pre-commit.com/#supported-git-hooks), so I think we should provide a sane default (stages: [pre-push]) to this hook (cf. https://pre-commit.com/#hooks-stages)

[HankyStyle]

Thanks. I can help with the follow-up PR if needed.

[Lee-W]

Thanks. I can help with the follow-up PR if needed.

We probably should just add it to this PR? Or is there any concern?