Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork941
Preserve quoted leading and trailing single-line config var whitespace#2036
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Merged
Uh oh!
There was an error while loading.Please reload this page.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
gitpython-developers#2035 fixed issuegitpython-developers#1923 by removing separate double quotation marksappearing on a single-line configuration variable when parsing aconfiguration file. However, it also stripped leading and trailingwhitespace from the string obtained by removing the quotes.This adds a test case of a plausible scenario where such whitespaceneeds to be preserved and where a user would almost certainly expectit to preserve: setting a value like `# ` for `core.commentString`,in order to be able to easily create commit messages like this one,that contain a line that begins with a literal `#`, while stillletting `#` in the more common case that it is followed by a spacebe interpreted as a comment.The effect of `git config --local core.commentString '# '` is toadd a `commentString = "# "` line in the `[core]` section of`.git/config`. The changes ingitpython-developers#2035 allow us to correctly parsemore quoted strings than before, and almost allow us to parse this,but not quite, because of the `strip()` operation that turns `# `into `#`.
At least in a single line, whitespace in a double-quoted value in aconfiguration file, like `name = " abc def "`, would presumably beintended. This removes the `strip()` call that is applied to text`ConfigParser` obtained by removing the double quotes around it.This slightly refines the changes ingitpython-developers#2035 by dropping the `strip()`call while continuing to remove opening and closing double quotes.
Byron approved these changesJun 7, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks a lot for this, a great catch!
cf8029d intogitpython-developers:main 26 checks passed
Uh oh!
There was an error while loading.Please reload this page.
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 7, 2025
In both the:- Unquoted case, where extra whitespace is at the edges of what can be parsed as the value.- Quoted case, where extra whitespace is next to but outside of the quotes.The case where the whitespace is at the edges of the quoted valueand *inside* the quotes, and thus part of the value, is alreadycovered ingitpython-developers#2036. (That is merely renamed here, to distinguish it.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 8, 2025
This is for single line quoting in the ConfigParser.This leaves the changes ingitpython-developers#2035 (as adjusted ingitpython-developers#2036) intact forthe cases where it addressedgitpython-developers#1923: when the `...` in `"..."`(appearing in the value position on a single `{name} = {value}"`line) has no occurrences of `\` or `"`, quote removal is enough.But when `\` or `"` does appear, this suppresses quote removal.This is with the idea that, while it would be better to interpretsuch lines as Git does, we do not yet do that, so it is preferableto return the same results we have in the past (which some programsmay already be handling themselves).This should make the test introduced in the preceding commit pass.But it will be even better to support more syntax, at leastwell-formed escapes. As noted in the test, both the test and thecode under test can be adjusted for that.(See comments ingitpython-developers#2035 for context.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 8, 2025
This is for single line quoting in the ConfigParser.This leaves the changes ingitpython-developers#2035 (as adjusted ingitpython-developers#2036) intact forthe cases where it addressedgitpython-developers#1923: when the `...` in `"..."`(appearing in the value position on a single `{name} = {value}"`line) has no occurrences of `\` or `"`, quote removal is enough.But when `\` or `"` does appear, this suppresses quote removal.This is with the idea that, while it would be better to interpretsuch lines as Git does, we do not yet do that, so it is preferableto return the same results we have in the past (which some programsmay already be handling themselves).This should make the test introduced in the preceding commit pass.But it will be even better to support more syntax, at leastwell-formed escapes. As noted in the test, both the test and thecode under test can be adjusted for that.(See comments ingitpython-developers#2035 for context.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 8, 2025
This is for single line quoting in the ConfigParser.This leaves the changes ingitpython-developers#2035 (as adjusted ingitpython-developers#2036) intact forthe cases where it addressedgitpython-developers#1923: when the `...` in `"..."`(appearing in the value position on a single `{name} = {value}"`line) has no occurrences of `\` or `"`, quote removal is enough.But when `\` or `"` does appear, this suppresses quote removal.This is with the idea that, while it would be better to interpretsuch lines as Git does, we do not yet do that, so it is preferableto return the same results we have in the past (which some programsmay already be handling themselves).This should make the test introduced in the preceding commit pass.But it will be even better to support more syntax, at leastwell-formed escapes. As noted in the test, both the test and thecode under test can be adjusted for that.(See comments ingitpython-developers#2035 for context.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 8, 2025
This is for single line quoting in the ConfigParser.This leaves the changes ingitpython-developers#2035 (as adjusted ingitpython-developers#2036) intact forthe cases where it addressedgitpython-developers#1923: when the `...` in `"..."`(appearing in the value position on a single `{name} = {value}"`line) has no occurrences of `\` or `"`, quote removal is enough.But when `\` or `"` does appear, this suppresses quote removal.This is with the idea that, while it would be better to interpretsuch lines as Git does, we do not yet do that, so it is preferableto return the same results we have in the past (which some programsmay already be handling themselves).This should make the test introduced in the preceding commit pass.But it will be even better to support more syntax, at leastwell-formed escapes. As noted in the test, both the test and thecode under test can be adjusted for that.(See comments ingitpython-developers#2035 for context.)
EliahKagan added a commit to EliahKagan/GitPython that referenced this pull requestJun 8, 2025
This is for single line quoting in the ConfigParser.This leaves the changes ingitpython-developers#2035 (as adjusted ingitpython-developers#2036) intact forthe cases where it addressedgitpython-developers#1923: when the `...` in `"..."`(appearing in the value position on a single `{name} = {value}"`line) has no occurrences of `\` or `"`, quote removal is enough.But when `\` or `"` does appear, this suppresses quote removal.This is with the idea that, while it would be better to interpretsuch lines as Git does, we do not yet do that, so it is preferableto return the same results we have in the past (which some programsmay already be handling themselves).This should make the test introduced in the preceding commit pass.But it will be even better to support more syntax, at leastwell-formed escapes. As noted in the test, both the test and thecode under test can be adjusted for that.(See comments ingitpython-developers#2035 for context.)
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Labels
None yet
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#2035 fixed issue#1923 by removing separate double quotation marks appearing on a single-line configuration variable when parsing a configuration file. However, as noted in#2035 (comment), it also stripped leading and trailing whitespace from the string obtained by removing the quotes.
In this PR:
strip()call while leaving the changes from#2035 otherwise intact. The test added in (1) fails until this change, and then passes.See the commit message for further details.