René's URL Explorer Experiment

Title: fix(git): tolerate noisy git rev-parse output in is_git_project by bearomorphism · Pull Request #1980 · commitizen-tools/commitizen · GitHub

Open Graph Title: fix(git): tolerate noisy git rev-parse output in is_git_project by bearomorphism · Pull Request #1980 · commitizen-tools/commitizen

X Title: fix(git): tolerate noisy git rev-parse output in is_git_project by bearomorphism · Pull Request #1980 · commitizen-tools/commitizen

Description: Description Closes #1497. Why Users running commitizen via uv tool install commitizen inside Git Bash on Windows 11 encounter NotAGitProjectError even though running git rev-parse --is-inside-work-tree manually in the same shell returns true. Commands that require a git context — cz commit, cz bump, cz changelog — all raise the error, while read-only commands such as cz info and cz ls succeed because they never call is_git_project(). The root cause is the single-line check at commitizen/git.py:316 (master): return c.out.strip() == "true" Some shell wrappers — including Git Bash's colour-prompt infrastructure and certain terminal emulators on Windows — inject ANSI CSI escape sequences (e.g., \x1b[0m) into subprocess standard output. When that happens, c.out.strip() yields "\x1b[0mtrue" rather than the bare string "true", the strict equality check fails silently, and is_git_project() returns False, triggering the error even inside a valid work tree. This was surfaced during the #1964 audit: "Depending on subprocess setup with uv tool install on git-bash for Windows, [the output] may not match exactly." Because the original reporter's exact environment couldn't be reproduced locally, the new --debug logging path provides the next-best diagnostic: any future reporter can run cz --debug commit and see the exact bytes returned by git rev-parse. What changed File Change commitizen/git.py Add _ANSI_ESCAPE compiled regex; rewrite is_git_project() to trust the exit code first, strip ANSI codes, then exact-match "true"; add logger.debug for both failure paths tests/test_git.py Add five targeted regression tests: inside-work-tree, outside-repo, ANSI-prefixed output (the #1497 case), bare-repo interior, and substring-true rejection (parametrised) How it works Exit-code-first gate: if git rev-parse returns non-zero, we are definitively outside any git context — is_git_project() returns False immediately, independent of output parsing. This handles the genuine "not a repo" case cleanly and makes the diagnostic log message (rc=128) unambiguous. ANSI stripping before comparison: the module-level constant _ANSI_ESCAPE = re.compile(r"\x1b\[[0-?]*[ -/]*[@-~]") (compiled once at import time) covers all CSI sequences — SGR colour codes, cursor commands, and resets. It is applied via .sub("", c.out) before .strip().lower(). Exact match, not substring (the non-obvious choice): after stripping ANSI codes the cleaned output is compared with == "true". An earlier draft used .lower().endswith("true"), which also accepts "untrue" or "nottrue" — strings git rev-parse would never emit, but which a defensive matcher should still reject. The ANSI-strip step is the only looseness introduced; the final comparison remains a full-string equality check. logger.debug diagnostics: both failure paths (non-zero exit and unexpected textual output) emit a DEBUG-level message that includes rc, out, and err. Running cz --debug commit will now surface the exact bytes returned by git rev-parse, eliminating guesswork for future environment-specific reports. Backward compatibility is_git_project() is an internal helper with no public API surface; all callers are within commitizen/commands/. In the standard path (exit code 0, output "true\n"), the new code is semantically identical to the original one-liner at commitizen/git.py:316. is_staging_clean() and every other helper in commitizen/git.py are untouched. All five new tests plus every previously-existing is_git_project / is_staging_clean test in tests/test_git.py continue to pass. 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: Claude following the guidelines 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 (see "Steps to Test" below) Update the documentation for the changes Documentation Changes is_git_project() is an internal helper with no user-facing documentation page. A full docstring explaining the exit-code-first logic and ANSI-strip rationale has been added to the function itself. Expected Behavior Scenario Outcome Inside a git work tree, clean subprocess output ("true\n") is_git_project() returns True — unchanged Outside any git repo (git rev-parse exits 128) is_git_project() returns False; --debug shows rc=128 and the fatal error text Inside a git work tree, output has ANSI colour prefix (e.g., "\x1b[0mtrue\r\n") is_git_project() returns True — regression fix for #1497 Inside .git of a bare repo (git rev-parse exits 0, output "false\n") is_git_project() returns False Output is a string containing "true" as a substring ("untrue", "nottrue") is_git_project() returns False Steps to Test This Pull Request git fetch fork fix/1497-better-not-a-git-project-diagnostics git checkout fork/fix/1497-better-not-a-git-project-diagnostics # 1. Targeted regression test. uv run pytest tests/test_git.py -k is_git_project -v # 2. Reproduce-the-bug-then-verify-the-fix sequence. # Simulate the ANSI-prefixed output that Git Bash on Windows injects before "true". python - <<'EOF' from unittest.mock import patch from commitizen import cmd, git # #1497 failure mode: shell wrapper prepends an ANSI SGR reset noisy = cmd.Command("\x1b[0mtrue\r\n", "", b"", b"", 0) with patch("commitizen.cmd.run", return_value=noisy): result = git.is_git_project() assert result is True, f"Expected True, got {result!r}" print("OK: ANSI-prefixed 'true' is accepted") # Defensive check: garbage substrings ending in "true" must still be rejected for bad in ("untrue", "nottrue", "test true false"): fake = cmd.Command(f"{bad}\n", "", b"", b"", 0) with patch("commitizen.cmd.run", return_value=fake): result = git.is_git_project() assert result is False, f"Expected False for {bad!r}, got {result!r}" print("OK: substring-'true' strings are all rejected") EOF Additional Context This fix was surfaced during the #1964 issue audit. The triage comment on #1497 identified commitizen/git.py:314–316 (master) as the likely culprit — the strict == "true" equality check fails when a shell wrapper injects ANSI colour codes into subprocess output, a documented behaviour of Git Bash on Windows when colour is enabled globally. Because the exact failure environment couldn't be reproduced locally, the new logger.debug path at both non-zero-exit and unexpected-output branches is the primary diagnostic improvement: it closes the feedback loop for any future reporter without requiring a code change.

Open Graph Description: Description Closes #1497. Why Users running commitizen via uv tool install commitizen inside Git Bash on Windows 11 encounter NotAGitProjectError even though running git rev-parse --is-inside-work-...

X Description: Description Closes #1497. Why Users running commitizen via uv tool install commitizen inside Git Bash on Windows 11 encounter NotAGitProjectError even though running git rev-parse --is-inside-work-...

Opengraph URL: https://github.com/commitizen-tools/commitizen/pull/1980

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width