Fix GitConfigParser not removing quotes from values #2035
Conversation
d233b4c to
67468a2
Compare
There was a problem hiding this comment.
I think this change is an improvement and is better than what we had before, but I also worry that it may break some existing code that uses GitPython, because it leaves various other shortcomings intact while also making their presence harder to detect.
The contents of a quoted value are not, in general, intended to be interpreted literally. For example, if programs are handling double-quoted strings themselves and handling \ sequences in them, then removing the quotes here without handling \ sequences will break that: those programs will go from working correctly to working incorrectly when they upgrade to the next version of GitPython.
That doesn't mean this change isn't worthwhile, but it makes me think we should go further in supporting the syntax of Git configuration files. I also wonder if we should really be handling the single-line and multi-line cases separately as we are, since, if I understand correctly, they are parsed in a unified way by Git and not as separate cases.
The \n, \t, various other \ sequences, treatment of unrecognized \ sequences as errors, and various other differences between what we have here and what Git does can be seen in the parse_value function in Git.
It's possible that I'm missing something. GitConfigParser is probably the part of the GitPython code that I have done the least with. If I open a PR to make changes here before receiving feedback, then I'll wait for a review before merging it.
gitpython-developers#2035 fixed issue gitpython-developers#1923 by removing separate double quotation marks appearing on a single-line configuration variable when parsing a a configuration file. However, it also stripped leading and trailing whitespace from the string obtained by removing the quotes. This adds a test case of a plausible scenario where such whitespace needs to be preserved and where a user would almost certainly expect it 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 still letting `#` in the more common case that it is followed by a space be interpreted as a comment. The effect of `git config --local core.commentString '# '` is to add a `commentString = "# "` line in the `[core]` section of `.git/config`. The changes in gitpython-developers#2035 allow us to correctly parse more 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 a configuration file, like `name = " abc def "`, would presumably be intended. This removes the `strip()` call that is applied to text `ConfigParser` obtained by removing the double quotes around it. This slightly refines the changes in gitpython-developers#2035 by dropping the `strip()` call while continuing to remove opening and closing double quotes.
gitpython-developers#2035 fixed issue gitpython-developers#1923 by removing separate double quotation marks appearing on a single-line configuration variable when parsing a configuration file. However, it also stripped leading and trailing whitespace from the string obtained by removing the quotes. This adds a test case of a plausible scenario where such whitespace needs to be preserved and where a user would almost certainly expect it 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 still letting `#` in the more common case that it is followed by a space be interpreted as a comment. The effect of `git config --local core.commentString '# '` is to add a `commentString = "# "` line in the `[core]` section of `.git/config`. The changes in gitpython-developers#2035 allow us to correctly parse more 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 a configuration file, like `name = " abc def "`, would presumably be intended. This removes the `strip()` call that is applied to text `ConfigParser` obtained by removing the double quotes around it. This slightly refines the changes in gitpython-developers#2035 by dropping the `strip()` call while continuing to remove opening and closing double quotes.
|
@betaboon Maybe you could provide us with a follow-up PR that handles the escape sequences which may be present inside of quoted values, to more correctly capture this. After all, the GitPython Git configuration parser is just an adapted INI parser, and that is inherently unable to capture all the subtleties, but we can try harder where we can - this is clearly one such opportunity. For anything serious, it's better to use |
The ConfigParser has supported this for a long time, but it is now done redundantly since gitpython-developers#2035. This adds a test for it, both to make clearer that it is intended to work and to allow verifying that it continues to hold once the legacy special-casing for it is removed.
The ConfigParser has supported this for a long time, but it is now done redundantly since gitpython-developers#2035. This adds a test for it, both to make clearer that it is intended to work and to allow verifying that it continues to hold once the legacy special-casing for it is removed.
Because `""` is a special case of `"..."` as parsed since gitpython-developers#2035.
closes #1923