Reject comments after implicit boolean config keys

[Byron]

Tasks

This section is for Byron only. Models continuing this PR must not add, remove, check, uncheck, rename, or reorder checkboxes here.

• refackiew

---

Everything below this line was generated by Codex GPT-6.

Created by Codex on behalf of Byron. Byron will review before this is ready to merge.

Git rejects bare config keys followed by # or ; comments. GitPython previously accepted those lines with the comment in the option name, and an = or : inside the comment could make the line look like an assignment.

Exclude comment markers from the shared option-name expression and require a full-line match for valueless options. Reading or editing these entries now raises ParsingError. Ordinary bare keys retain their implicit true value.

Validation

• Six regression cases compare rejection directly with Git, covering both markers, whitespace and adjacent comments, and assignment delimiters inside comments.
• The regression checks both boolean reads and attempted edits raise ParsingError, and a failed edit leaves the original file untouched. All six cases failed before full-line matching was added.
• Python 3.12.14: 42 configuration tests and six regression subtests passed; two existing tests skipped.
• Ruff lint and formatting and git diff --check passed.
• Tix change vxuttnt, commit 2d4f068 (fix: reject comments after implicit boolean config keys).
• The single codex review --commit 2d4f0683341cb77e75a8656484d3c09a441f9d22 attempt could not complete because the Codex CLI refresh token has expired.

Git reference

Inspected Git checkout 1630431f326e15fcde608827b5ff38422528eb59, particularly config.c:get_value. Without an assignment, Git requires the line to end after the key and optional whitespace. Git 2.50.1 (Apple Git-155) rejects all six regression inputs with exit status 128.

Reported issue

The compatibility requirement was clarified to match Git's rejection of these entries. Original report:

Follow-up to PR 2238:

This matches the valueless-option regex against the unprocessed line, so a valid Git entry such as enabled # comment (or enabled ; comment) is stored with the comment text in the option name instead of as enabled. A write-back then emits that text as part of the key, and getboolean("flag", "enabled") still cannot find the option; strip the unquoted comment before extracting the name and add a regression for it.

[Copilot]

🟢 Approval recommended

The reviewed changes and regression coverage address the stated parsing issue.

Pull request overview

Fixes parsing and round-tripping of implicit boolean keys followed by # or ; comments.

Changes:

• Stops option matching at comment markers.
• Adds regression coverage for parsing, boolean access, and write-back.

File summaries

File	Summary
test/test_config.py	Adds comment-handling regression tests.
git/config.py	Updates assignment and valueless-key regex handling.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Byron]

Actually these have to be rejected, just like in Git.

[Copilot]

🟡 Changes recommended

The parser and regression tests do not implement or verify the intended comment-handling behavior.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite