| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
A `#` or `;` outside quotes starts a comment in git, with or without a space before it and whether or not the value is quoted. The parser only cut a `;` that was preceded by whitespace in an unquoted value, so `name = Alice # work` read back with the comment attached, and `k = "quoted" # after` was mistaken for an unterminated multi-line quote and returned `quoted" # after`. `strip_inline_comment` cuts the comment before the quote-structure branches, using the same quote- and escape-aware scan that `is_line_continuation` already uses, so all three branches see comment-free text. Escape handling is untouched. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
- [P2] Preserve balanced quote state after removing comments — git/config.py:596-596 For valid Git syntax such as `k = "foo"bar # "note"` followed by `x = keep`, stripping produces `"foo"bar`, which the subsequent last-character check misclassifies as an open multiline quote. On `main`, `x` and later sections remained separate entries; this change absorbs them into `k`, and writing an unrelated setting removes them from the config. Classify the stripped value using its actual quote state and add a regression test covering subsequent settings. Assisted-by: GPT 6.0 Co-authored-by: GPT 6.0 <codex@openai.com>
|
Thanks. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
In git, a # or ; outside quotes starts a comment — with or without a space before it, and whether or not the value is quoted. GitConfigParser cut only a ; that was preceded by whitespace in a value that did not start with ":
Measured against git config -f <file> --get a.k on git 2.50.1:
The last row is the worst of them: because the value starts with " and does not end with one, the comment made it look like an unterminated quote, so it was read as the start of a multi-line value and the following lines were swallowed into it.
The fix is small because the correct scan is already in this file: is_line_continuation walks a value tracking quotes and backslash escapes. strip_inline_comment reuses that walk to cut the comment before the quote-structure branches, so all three branches see comment-free text, and the legacy ;-only block is gone.
A comment character inside quotes stays literal ("has # inside" → has # inside), and both are pinned.
Escape handling is deliberately untouched. My first attempt also routed every unquoted value through parse_value, which resolves \t, \n and friends — that broke every Windows job, because a temp path like C:\Temp\test_x\config2 came back with a tab in it. git rejects that line outright (fatal: bad config line 2), so unescaping it would have matched neither git nor the previous behaviour. Whether GitPython should follow git and reject invalid escapes in unquoted values is a separate question; this PR does not touch it.
Verification: test/test_config.py is 46 passed, 2 skipped, 14 subtests. Reverting only git/config.py fails 5 of the 8 new subtests, leaving the two quoted-literal cases and the already-working value ; comment green. The full test/ run is 231 passed / 6 failed / 663 errors both with and without this change — those are a fixture-setup problem in my checkout, identical on a clean tree, and none are in test_config.py.
Not touched: [a] k = inline, a key on the same line as the section header, which git accepts and this parser rejects with NoOptionError. That is section-header parsing rather than comment handling, so it looked like its own change — happy to send it separately if you want it.