|
e51e29e8
|
2017-11-12T13:59:47
|
|
config_parse: have `git_config_parse` own entry value and name
The function `git_config_parse` uses several callbacks to pass data
along to the caller as it parses the file. One design shortcoming here
is that strings passed to those callbacks are expected to be freed by
them, which is really confusing.
Fix the issue by changing memory ownership here. Instead of expecting
the `on_variable` callbacks to free memory for `git_config_parse`, just
do it inside of `git_config_parse`. While this obviously requires a bit
more memory allocation churn due to having to copy both name and value
at some places, this shouldn't be too much of a burden.
|
|
|
ecf4f33a
|
2018-02-08T11:14:48
|
|
Convert usage of `git_buf_free` to new `git_buf_dispose`
|
|
|
ba4faf6e
|
2018-02-08T17:15:33
|
|
buf_text: remove `offset` parameter of BOM detection function
The function to detect a BOM takes an offset where it shall look for a
BOM. No caller uses that, and searching for the BOM in the middle of a
buffer seems to be very unlikely, as a BOM should only ever exist at
file start.
Remove the parameter, as it has already caused confusion due to its
weirdness.
|
|
|
2eea5f1c
|
2018-02-08T10:27:31
|
|
config_parse: fix reading files with BOM
The function `skip_bom` is being used to detect and skip BOM marks
previously to parsing a configuration file. To do so, it simply uses
`git_buf_text_detect_bom`. But since the refactoring to use the parser
interface in commit 9e66590bd (config_parse: use common parser
interface, 2017-07-21), the BOM detection was actually broken.
The issue stems from a misunderstanding of `git_buf_text_detect_bom`. It
was assumed that its third parameter limits the length of the character
sequence that is to be analyzed, while in fact it was an offset at which
we want to detect the BOM. Fix the parameter to be `0` instead of the
buffer length, as we always want to check the beginning of the
configuration file.
|
|
|
848153f3
|
2018-02-08T10:02:29
|
|
config_parse: handle empty lines with CRLF
Currently, the configuration parser will fail reading empty lines with
just an CRLF-style line ending. Special-case the '\r' character in order
to handle it the same as Unix-style line endings. Add tests to spot this
regression in the future.
|
|
|
5340ca77
|
2018-02-08T09:31:51
|
|
config_parse: add comment to clarify logic getting next character
Upon each line, the configuration parser tries to get either the first
non-whitespace character or the first whitespace character, in case
there is no non-whitespace character. The logic handling this looks
rather odd and doesn't immediately convey this meaning, so add a comment
to clarify what happens.
|
|
|
9e66590b
|
2017-07-21T13:01:43
|
|
config_parse: use common parser interface
As the config parser is now cleanly separated from the config file code,
we can easily refactor the code and make use of the common parser
module. This removes quite a lot of duplicated functionality previously
used for handling the actual parser state and replaces it with the
generic interface provided by the parser context.
|
|
|
1953c68b
|
2017-11-11T17:12:31
|
|
config_file: split out module to parse config files
The configuration file code grew quite big and intermingles both actual
configuration logic as well as the parsing logic of the configuration
syntax. This makes it hard to refactor the parsing logic on its own and
convert it to make use of our new parsing context module.
Refactor the code and split it up into two parts. The config file code
will only handle actual handling of configuration files, includes and
writing new files. The newly created config parser module is then only
responsible for parsing the actual contents of a configuration file,
leaving everything else to callbacks provided to its provided function
`git_config_parse`.
|