kmx git

Commit	Date	Message
02683b20	2019-01-12T23:06:39	regexec: prefix all regexec function calls with p_ Prefix all the calls to the the regexec family of functions with `p_`. This allows us to swap out all the regular expression functions with our own implementation. Move the declarations to `posix_regex.h` for simpler inclusion.
e44110db	2019-03-20T12:28:45	Correctly write to missing locked global config Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string.
bc5b19e6	2019-04-29T09:01:45	Merge pull request #4561 from pks-t/pks/downcasting [RFC] util: introduce GIT_DOWNCAST macro
cc8a9892	2019-04-16T18:13:31	config_file: check result of git_array_alloc git_array_alloc can return NULL if no memory is available, causing a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC similar to how other parts of the code base deal with the return value of git_array_alloc.
65203b5a	2019-04-16T13:21:16	config_file: make use of `GIT_CONTAINER_OF` macro
f673e232	2018-12-27T13:47:34	git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.
d06d4220	2018-10-05T10:56:02	config_file: properly ignore includes without "path" value In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810.
b78f4ab0	2018-08-16T12:22:03	config_entries: refactor entries iterator memory ownership Right now, the config file code requires us to pass in its backend to the config entry iterator. This is required with the current code, as the config file backend will first create a read-only snapshot which is then passed to the iterator just for that purpose. So after the iterator is getting free'd, the code needs to make sure that the snapshot gets free'd, as well. By now, though, we can easily refactor the code to be more efficient and remove the reverse dependency from iterator to backend. Instead of creating a read-only snapshot (which also requires us to re-parse the complete configuration file), we can simply duplicate the config entries and pass those to the iterator. Like that, the iterator only needs to make sure to free the duplicated config entries, which is trivial to do and clears up memory ownership by a lot.
123e5963	2018-08-10T18:59:59	config_entries: abstract away reference counting Instead of directly calling `git_atomic_inc` in users of the config entries store, provide a `git_config_entries_incref` function to further decouple the interfaces. Convert the refcount to a `git_refcount` structure while at it.
5a7e0b3c	2018-08-10T18:49:38	config_entries: abstract away iteration over entries The nice thing about our `git_config_iterator` interfaces is that nobody needs to know anything about the implementation details. All that is required is to obtain the iterator via any backend and then use it by executing generic functions. We can thus completely internalize all the implementation details of how to iterate over entries into the config entries store and simply create such an iterator in our config file backend when we want to iterate its entries. This further decouples the config file backend from the config entries store.
60ebc137	2018-08-10T14:53:09	config_entries: abstract away retrieval of config entries The code accessing config entries in the `git_config_entries` structure is still much too intimate with implementation details, directly accessing the maps and handling indices. Provide two new functions to get config entries from the internal map structure to decouple the interfaces and use them in the config file code. The function `git_config_entries_get` will simply look up the entry by name and, in the case of a multi-value, return the last occurrence of that entry. The second function, `git_config_entries_get_unique`, will only return an entry if it is unique and not included via another configuration file. This one is required to properly implement write operations for single entries, as we refuse to write to or delete a single entry if it is not clear which one was meant.
fb8a87da	2018-08-10T14:50:15	config_entries: rename functions and structure The previous commit simply moved all code that is required to handle config entries to a new module without yet adjusting any of the function and structure names to help readability. We now rename things accordingly to have a common "git_config_entries" entries instead of the old "diskfile_entries" one.
04f57d51	2018-08-10T13:33:02	config_entries: pull out implementation of entry store The configuration entry store that is used for configuration files needs to keep track of all entries in two different structures: - a singly linked list is being used to be able to iterate through configuration files in the order they have been found - a string map is being used to efficiently look up configuration entries by their key This store is thus something that may be used by other, future backends as well to abstract away implementation details and iteration over the entries. Pull out the necessary functions from "config_file.c" and moves them into their own "config_entries.c" module. For now, this is simply moving over code without any renames and/or refactorings to help reviewing.
d75bbea1	2018-08-10T14:35:23	config_file: remove unnecessary snapshot indirection The implementation for config file snapshots has an unnecessary redirection from `config_snapshot` to `git_config_file__snapshot`. Inline the call to `git_config_file__snapshot` and remove it.
b944e137	2018-08-10T13:03:33	config: rename "config_file.h" to "config_backend.h" The header "config_file.h" has a list of inline-functions to access the contents of a config backend without directly messing with the struct's function pointers. While all these functions are called "git_config_file_", they are in fact completely backend-agnostic and don't care whether it is a file or not. Rename all the function to instead be backend-agnostic versions called "git_config_backend_" and rename the header to match.
1aeff5d7	2018-08-10T12:52:18	config: move function normalizing section names into "config.c" The function `git_config_file_normalize_section` is never being used in any file different than "config.c", but it is implemented in "config_file.c". Move it over and make the symbol static.
f2694635	2018-09-06T14:17:54	config_file: fix quadratic behaviour when adding config multivars In case where we add multiple configuration entries with the same key to a diskfile backend, we always need to iterate the list of this key to find the last entry due to the list being a singly-linked list. This is obviously quadratic behaviour, and this has sure enough been found by oss-fuzz by generating a configuration file with 50k lines, where most of them have the same key. While the issue will not arise with "sane" configuration files, an adversary may trigger it by providing a crafted ".gitmodules" file, which is delivered as part of the repo and also parsed by the configuration parser. The fix is trivial: store a pointer to the last entry of the list in its head. As there are only two locations now where we append to this data structure, mainting this pointer is trivial, too. We can also optimize retrieval of a single value via `config_get`, where we previously had to chase the `next` pointer to find the last entry that was added. Using our configuration file fozzur with a corpus that has a single file with 50000 "-=" lines previously took around 21s. With this optimization the same file scans in about 0.053s, which is a nearly 400-fold improvement. But in most cases with a "normal" amount of same-named keys it's not going to matter anyway.
ec76a1aa	2018-08-05T14:37:08	Add a comment
019409be	2018-08-05T14:25:22	Don't error on missing section, just continue
c4d7fa95	2018-07-22T23:31:19	config_file: Don't crash on options without a section
e1e90dcc	2018-01-09T14:52:34	config_file: avoid free'ing OOM buffers Buffers which ran out of memory will never have any memory attached to them. As such, it is not necessary to call `git_buf_free` if the buffer is out of memory.
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`
6a15f657	2018-02-09T13:02:26	config_file: iterate over keys in the order they were added Currently, all configuration entries were only held in a string map, making iteration order mostly based on the hash of each entry's key. Now that we have extended the `diskfile_entries` structure by a list of config entries, we can effectively iterate through entries in the order they were added, though.
3a82475f	2018-02-09T12:49:45	config_file: add list holding config entries in order of appearance Right now, we only keep all configuration entries in a string map. This is required to efficiently access configuration entries by keys. It has the disadvantage of not being able to iterate through configuration entries in the order they were read, though. Instead, we only iterate through entries in a seemingly random order. Extend `diskfile_entries` by another list holding configuration entries. Like this, we maintain all entries in two data structures and can use the required one based on the current use case.
8c0b0717	2018-02-09T12:32:24	config_file: pass complete entry structure into `append_entry` Currently, we only parse the entry map into `append_entry` to append new configuration entries to it. Instead, though, we can just pass the complete `diskfile_entries` structure into it. This allows us to easily extend `diskfile_entries` by another singly linked list of configuration entries.
eafb8402	2018-02-09T12:29:16	config_file: rename `refcounted_strmap` to `diskfile_entries` The config file parsing code all revolves around the `refcounted_strmap` structure, which is a map of entry names to their respective keys. This naming scheme made grasping the code quite hard, warranting a rename. A good alternative is `diskfile_entries`, making clear that this really only holds all configuration entries. Furthermore, we are about to introduce a new linked list of configuration entries into the configuration file code. This list will be used to iterate over configuration entries in the order they are listed inside of the parsed configuration file. After renaming `refcounted_strmap` to `diskfile_entries`, this struct also becomes the natural target where to add that new list. Like this, data structures holding all entries are neatly contained inside of it.
e3c8462c	2018-02-09T11:50:28	config_file: rename parse_data struct The struct `parse_data` sounds as if it was defined and passed to us from the configuration parser, which is not true. Instead, `parse_data` is specific to the diskfile backend parsing logic. Rename it to `diskfile_parse_state` to make that clearer. This also follows existing naming patterns with the "diskfile" prefix.
18117a6c	2018-02-09T11:43:13	config_file: use new line to declare new variable
b6f88706	2018-02-09T11:39:26	config_file: refactor freeing of config entry lists The interface for freeing config list entries is more tangled than required. Instead of calling `cvar_free` for every list entry in `free_vars`, we now just provide a function `config_entry_list_free`. This function will iterate through all list entries and free the associated configuration entry as well as the list entry itself.
2d1f6676	2018-02-09T11:35:54	config_file: rename cvar_t struct to config_entry_list The `cvar_t` structure is really awkward to grasp, because its name actively hinders discovery of what it actually is. As it is nothing more than a singly-linked list of configuration entries, name rename it to just that: `config_entry_list`.
26cf48fc	2018-02-09T11:35:16	config_file: move include depth into config entry In order to reject writes to included configuration entries, we need to keep track of whether an entry was included via another configuration file or not. This information is being stored in the `cvar` structure, which is a rather weird location, as it is only used to create a list structure of config entries. Move the include depth into the structure `git_config_entry` instead. While this fixes the layering issue, it enables users of libgit2 to access the depth, too.
fcb0d841	2018-02-09T11:19:47	config_file: move cvar handling into `append_entry` The code appending new configuration entries to our current list first allocates the `cvar` structure and then passes it to `append_entry`. As we want to extend `append_entry` to store configuration entries in a map as well as in a list for ordered iteration, we will have to create two `cvar` structures, though. As such, the future change will become much easier when allocation of the `cvar` structure is doen in `append_entry` itself.
dfcd923c	2018-02-09T11:15:32	config_file: remove unused list iteration macros We currently provide a lot of macros for the `cvar_t` structure which are never being used. In fact, the only macro we need is to access the `next` pointer of `cvar_t`, which really does not require a macro at all. Remove all these macros and replace usage of `CVAR_LIST_NEXT(cvar)` with `cvar->next`.
9cd0c6f1	2018-02-28T16:01:16	config: return an error if config_refresh is called on a snapshot Instead of treating it as a no-op, treat it as a programming error and return the same kind of error as if you called to set or delete variables on a snapshot.
2424e64c	2018-02-28T12:06:02	config: harden our use of the backend objects a bit When we create an iterator we don't actually know that we have a live config object and we must instead only rely on the header. We fixed it to use this in a previous commit, but this makes it harder to misuse by converting to use the header object in the typecast. We also guard inside the `config_refresh` function against being given a snapshot (although callers right now do check).
1785de4e	2018-02-28T11:46:17	config: move the level field into the header We use it in a few places where we might have a full object or a snapshot so move it to where we can actually access it.
c1524b2e	2018-02-28T11:33:11	config: move the repository to the diskfile header We pass this around and when creating a new iterator we need to read the repository pointer. Put it in a common place so we can reach it regardless of whether we got a full object or a snapshot.
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`.
42627933	2017-11-04T18:03:26	Merge remote-tracking branch 'upstream/master' into pks/conditional-includes
1475b981	2017-11-04T18:00:56	config: keep the output parameter at the start of the function
94e30d9b	2017-10-30T15:55:18	config: check for OOM when writing
8ec806d7	2017-10-30T06:23:31	config: preserve the original case when writing out new sections and vars For sections we will still use the existing one even if the case disagrees, but the variable always gets written with the case given by the caller.
f7d837c8	2017-05-24T12:12:29	config_file: implement "gitdir/i" conditional Next to the "gitdir" conditional for including other configuration files, there's also a "gitdir/i" conditional. In contrast to the former one, path matching with "gitdir/i" is done case-insensitively. This commit implements the case-insensitive condition.
071b6c06	2017-05-24T11:13:36	config_file: implement conditional "gitdir" includes Upstream git.git has implemented the ability to include other configuration files based on conditions. Right now, this only includes the ability to include a file based on the gitdir-location of the repository the currently parsed configuration file belongs to. This commit implements handling these conditional includes for the case-sensitive "gitdir" condition.
9d7a75be	2017-08-25T19:15:00	config_file: make repo and config path accessible to reader The reader machinery will be extended to handle conditional includes. The only conditions that currently exist all match the against the git directory of the repository the config file belongs to. As such, we need to have access to the repository when reading configuration files to properly handle these conditions. One specialty of thes conditional includes is that the actual pattern may also be a relative pattern starting with "./". In this case, we have to match the pattern against the path relative to the config file which is currently being parsed. So besides the repository, we also have to pass down the path to the current config file that is being parsed.
d5b9d9e9	2017-05-23T10:53:49	config_file: extract function to parse include path The logic inside this function will be required later on, when implementing conditional includes. Extract it into its own function to ease the implementation.
529e873c	2017-05-23T11:51:00	config: pass repository when opening config files Our current configuration logic is completely oblivious of any repository, but only cares for actual file paths. Unfortunately, we are forced to break this assumption by the introduction of conditional includes, which are evaluated in the context of a repository. Right now, only one conditional exists with "gitdir:" -- it will only include the configuration if the current repository's git directory matches the value passed to "gitdir:". To support these conditionals, we have to break our API and make the repository available when opening a configuration file. This commit extends the `open` call of configuration backends to include another repository and adjusts existing code to have it available. This includes the user-visible functions `git_config_add_file_ondisk` and `git_config_add_backend`.
1560b580	2017-08-15T10:35:47	Merge pull request #4288 from pks-t/pks/include-fixups Include fixups
1b329089	2017-05-31T22:27:19	config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.
28c2cc3d	2017-05-31T16:41:44	config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.
83bcd3a1	2017-05-31T22:45:25	config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.
56a7a264	2017-05-31T14:50:40	config_file: remove unused backend field from parse data The backend passed to `config_read` is never actually used anymore, so we can remove it from the function and the `parse_data` structure.
3a7f7a6e	2017-05-31T14:43:46	config_file: pass reader directly to callbacks Previously, the callbacks passed to `config_parse` got the reader via a pointer to a pointer. This allowed the callbacks to update the callers `reader` variable when the array holding it has been reallocated. As the array is no longer present, we can simply the code by making the reader a simple pointer.
73df75d8	2017-05-31T14:34:48	config_file: refactor include handling Current code for configuration files uses the `reader` structure to parse configuration files and store additional metadata like the file's path and checksum. These structures are stored within an array in the backend itself, which causes multiple problems. First, it does not make sense to keep around the file's contents with the backend itself. While this data is usually free'd before being added to the backend, this brings along somewhat intricate lifecycle problems. A better solution would be to store only the file paths as well as the checksum of the currently parsed content only. The second problem is that the `reader` structures are stored inside an array. When re-parsing configuration files due to changed contents, we may cause this array to be reallocated, requiring us to update pointers hold by callers. Furthermore, we do not keep track of includes which are already associated to a reader inside of this array. This causes us to add readers multiple times to the backend, e.g. in the scenario of refreshing configurations. This commit fixes these shortcomings. We introduce a split between the parsing data and the configuration file's metadata. The `reader` will now only hold the file's contents and the parser state and the new `config_file` structure holds the file's path and checksum. Furthermore, the new structure is a recursive structure in that it will also hold references to the files it directly includes. The diskfile is changed to only store the top-level configuration file. These changes allow us further refactorings and greatly simplify understanding the code.
0c7f49dd	2017-06-30T13:39:01	Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.
a693b873	2017-06-07T10:20:44	buffer: use `git_buf_init` with length The `git_buf_init` function has an optional length parameter, which will cause the buffer to be initialized and allocated in one step. This can be used instead of static initialization with `GIT_BUF_INIT` followed by a `git_buf_grow`. This patch does so for two functions where it is applicable.
a1023a43	2017-05-20T17:18:07	Merge pull request #4179 from libgit2/ethomson/expand_tilde Introduce home directory expansion function for config files, attribute files
4467aeac	2017-03-28T09:00:48	config_file: handle errors other than OOM while parsing section headers The current code in `parse_section_header_ext` is only prepared to properly handle out-of-memory conditions for the `git_buf` structure. While very unlikely and probably caused by a programming error, it is also possible to run into error conditions other than out-of-memory previous to reaching the actual parsing loop. In these cases, we will run into undefined behavior as the `rpos` variable is only initialized after these triggerable errors, but we use it in the cleanup-routine. Fix the issue by unifying the function's cleanup code with an `end_error` section, which will not use the `rpos` variable.
29aef948	2017-03-23T11:59:06	config, attrcache: don't fallback to dirs literally named `~` The config and attrcache file reading code would attempt to load a file in a home directory by expanding the `~` and looking for the file, using `git_sysdir_find_global_file`. If the file was not found, the error handling would look for the literal path, eg `~/filename.txt`. Use the new `git_config_expand_global_file` instead, which allows us to get the path to the file separately, when the path is prefixed with `~/`, and fail with a not found error without falling back to looking for the literal path.
301dc26a	2016-06-20T13:15:35	fix error when including a missing config file relative to the home directory
2cf48e13	2017-03-20T09:34:41	config_file: check if section header buffer runs out of memory While parsing section headers, we use a buffer to store the actual section name. We do not check though if the buffer runs out of memory at any stage. Do so.
13c3bc9a	2017-01-27T14:32:23	strmap: remove GIT__USE_STRMAP macro
73028af8	2017-01-27T14:20:24	khash: avoid using macro magic to get return address
909d5494	2016-12-29T12:25:15	giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one
ab96ca55	2016-10-06T13:15:31	Make sure we use the `C` locale for `regcomp` on macOS.
2f0450f4	2016-03-29T03:26:43	Merge pull request #3712 from ethomson/config_duplicate_section config: don't write duplicate section
e25e1ca1	2016-03-28T11:13:51	config: don't write section header if we're in it If we hit the EOF while trying to write a new value, it may be that we're already in the section that we were looking for. If so, do not write a (duplicate) section header, just write the value.
6f09911c	2016-03-21T21:10:26	config: don't special-case multivars that don't exist yet This special-casing ignores that we might have a locked file, so the hashtable does not represent the contents of the file we want to write. This causes multivar writes to overwrite entries instead of add to them when under lock. There is no need for this as the normal code-path will write to the file just fine, so simply get rid of it.
77394a27	2016-03-14T19:15:20	Merge pull request #3677 from pks-t/pks/coverity-fixes-round7 Coverity fixes round 7
836447e5	2016-03-10T16:52:09	config_file: handle error when trying to lock strmap Accessing the current values map is handled through the `refcounder_strmap_take` function, which first acquires a mutex before accessing its values. While this assures everybody is trying to access the values with the mutex only we do not check if the locking actually succeeds. Fix the issue by checking if acquiring the lock succeeds and returning `NULL` if we encounter an error. Adjust callers.
e126bc95	2016-03-01T14:40:17	config_file: handle missing quotation marks in section header When parsing a section header we expect something along the format of '[section "subsection"]'. When a section is mal-formated and is entirely missing its quotation marks we catch this case by observing that `strchr(line, '"') - strrchr(line, '"') = NULL - NULL = 0` and error out. Unfortunately, the error message is misleading though, as we state that we are missing the closing quotation mark while we in fact miss both quotation marks. Improve the error message by explicitly checking if the first quotation mark could be found and, if not, stating that quotation marks are completely missing.
eb597799	2015-10-29T21:12:37	filebuf: use a checksum to detect file changes Instead of relying on the size and timestamp, which can hide changes performed in the same second, hash the file content's when we care about detecting changes.
cd677b8f	2015-09-18T12:28:05	config: buffer comments to match git's variable-adding When there is a comment at the end of a section, git keeps it there, while we write the new variable right at the end. Keep comments buffered and dump them when we're going to output a variable or section, or reach EOF. This puts us in line with the config files which git produces.
b1667039	2015-06-01T19:17:03	config: implement basic transactional support When a configuration file is locked, any updates made to it will be done to the in-memory copy of the file. This allows for multiple updates to happen while we hold the lock, preventing races during complex config-file manipulation.
3ce9e4d2	2015-06-01T08:45:15	config: write the modified file to memory Instead of writing into the filebuf directly, make the functions to write the modified config file write into a buffer which can then be dumped into the lockfile for committing. This allows us to re-use the same code for modifying a locked configuration, as we can simply skip the last step of dumping the data to disk.
75a4636f	2015-05-29T16:56:38	git__tolower: a tolower() that isn't dumb Some brain damaged tolower() implementations appear to want to take the locale into account, and this may require taking some insanely aggressive lock on the locale and slowing down what should be the most trivial of trivial calls for people who just want to downcase ASCII.
b162d97a	2015-05-05T09:47:16	config: plug a couple of leaks
63c0cc65	2015-04-27T16:29:00	config: cleanup some now-unused variables
9c26de0f	2015-04-27T15:38:44	config: lock the file for write before reading When writing a configuration file, we want to take a lock on the new file (eg, `config.lock`) before opening the configuration file (`config`) for reading so that we can prevent somebody from changing the contents underneath us.
2a950c94	2015-04-27T10:43:50	config: write existing lines as-is when rewriting When updating a configuration file, we want to copy the old data from the file to preserve comments and funny whitespace, instead of writing it in some "canonical" format. Thus, we keep a pointer to the start of the line and the line length to preserve these things we don't care to rewrite.
bf99390e	2015-04-23T16:54:36	config: examine whole file when writing Previously we would try to be clever when writing the configuration file and try to stop parsing (and simply copy the rest of the old file) when we either found the value we were trying to write, or when we left the section that value was in, the assumption being that there was no more work to do. Regrettably, you can have another section with the same name later in the file, and we must cope with that gracefully, thus we read the whole file in order to write a new file. Now, writing a file looks even more than reading. Pull the config parsing out into its own function that can be used by both reading and writing the configuration.
d369d71f	2015-04-21T17:18:35	config: peek returns '\n' on EOF; handle in write
2c8c00c6	2015-04-21T12:52:29	config: validate config keys
9a810c5e	2015-04-16T15:32:16	git_config_delete: search until last section. If git_config_delete is to work properly in the presence of duplicate section headers, it cannot stop searching at the end of the first matching section, as there may be another matching section later. When config_write is used for deletion (value = NULL), it may only terminate when the desired key is found or there are no sections left to parse.
e009a705	2015-04-20T00:22:20	config_file: comment char can be invalid escape Don't assume that comment chars are comment chars, they may be (an attempt to be escaped). If so, \; is not a valid escape sequence, complain.
7f2e61f3	2015-04-19T23:55:02	config_file: parse multilines generously Combine unquoting and multiline detection to avoid ambiguity when parsing.
129022ee	2015-04-10T09:36:38	Fix checking of return value for regcomp. The regcomp function returns a non-zero value if compilation of a regular expression fails. In most places we only check for negative values, but positive values indicate an error, as well. Fix this tree-wide, fixing a segmentation fault when calling git_config_iterator_glob_new with an invalid regexp.
9a97f49e	2014-12-21T15:31:03	config: borrow refcounted references This changes the get_entry() method to return a refcounted version of the config entry, which you have to free when you're done. This allows us to avoid freeing the memory in which the entry is stored on a refresh, which may happen at any time for a live config. For this reason, get_string() has been forbidden on live configs and a new function get_string_buf() has been added, which stores the string in a git_buf which the user then owns. The functions which parse the string value takea advantage of the borrowing to parse safely and then release the entry.
c8e02b87	2015-02-15T21:07:05	Remove extra semicolon outside of a function Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
a7fa970f	2015-02-15T05:13:50	Merge pull request #2895 from ethomson/alloc_overflow allocations: test for overflow of requested size
f1453c59	2015-02-12T12:19:37	Make our overflow check look more like gcc/clang's Make our overflow checking look more like gcc and clang's, so that we can substitute it out with the compiler instrinsics on platforms that support it. This means dropping the ability to pass `NULL` as an out parameter. As a result, the macros also get updated to reflect this as well.
2884cc42	2015-02-11T09:39:38	overflow checking: don't make callers set oom Have the ALLOC_OVERFLOW testing macros also simply set_oom in the case where a computation would overflow, so that callers don't need to.
392702ee	2015-02-09T23:41:13	allocations: test for overflow of requested size Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.
17136538	2015-02-05T23:39:59	Reinit `reader` pointer after reading included config file Fixes #2869. If included file includes more files, it may reallocate cfg_file->readers, hence invalidate not only `r` pointer, but `result` pointer as well.
6f73e026	2014-12-24T11:42:50	Plug some leaks
b874629b	2014-12-04T21:06:59	Spelling fixes
ebc13b2b	2014-11-02T19:16:49	Clean up issues include.path issues found during code review. * Error-handling is cleaned up to only let a file-not-found error through, not other sorts of errors. And when a file-not-found error happens, we clean up the error. * Test now checks that file-not-found introduces no error. And other minor cleanups.
727ae380	2014-11-01T11:21:45	Make config reading continue after hitting a missing include file. For example, if you have [include] path = foo and foo didn't exist, git_config_open_ondisk() would just give up on the rest of the file. Now it ignores the unresolved include without error and continues reading the rest of the file.

02683b20

2019-01-12T23:06:39

regexec: prefix all regexec function calls with p_ Prefix all the calls to the the regexec family of functions with `p_`. This allows us to swap out all the regular expression functions with our own implementation. Move the declarations to `posix_regex.h` for simpler inclusion.

e44110db

2019-03-20T12:28:45

Correctly write to missing locked global config Opening a default config when ~/.gitconfig doesn't exist, locking it, and attempting to write to it causes an assertion failure. Treat non-existent global config file content as an empty string.

bc5b19e6

2019-04-29T09:01:45

Merge pull request #4561 from pks-t/pks/downcasting [RFC] util: introduce GIT_DOWNCAST macro

cc8a9892

2019-04-16T18:13:31

config_file: check result of git_array_alloc git_array_alloc can return NULL if no memory is available, causing a segmentation fault in memset. This adds GIT_ERROR_CHECK_ALLOC similar to how other parts of the code base deal with the return value of git_array_alloc.

65203b5a

2019-04-16T13:21:16

config_file: make use of `GIT_CONTAINER_OF` macro

f673e232

2018-12-27T13:47:34

git_error: use new names in internal APIs and usage Move to the `git_error` name in the internal API for error-related functions.

d06d4220

2018-10-05T10:56:02

config_file: properly ignore includes without "path" value In case a configuration includes a key "include.path=" without any value, the generated configuration entry will have its value set to `NULL`. This is unexpected by the logic handling includes, and as soon as we try to calculate the included path we will unconditionally dereference that `NULL` pointer and thus segfault. Fix the issue by returning early in both `parse_include` and `parse_conditional_include` in case where the `file` argument is `NULL`. Add a test to avoid future regression. The issue has been found by the oss-fuzz project, issue 10810.

b78f4ab0

2018-08-16T12:22:03

config_entries: refactor entries iterator memory ownership Right now, the config file code requires us to pass in its backend to the config entry iterator. This is required with the current code, as the config file backend will first create a read-only snapshot which is then passed to the iterator just for that purpose. So after the iterator is getting free'd, the code needs to make sure that the snapshot gets free'd, as well. By now, though, we can easily refactor the code to be more efficient and remove the reverse dependency from iterator to backend. Instead of creating a read-only snapshot (which also requires us to re-parse the complete configuration file), we can simply duplicate the config entries and pass those to the iterator. Like that, the iterator only needs to make sure to free the duplicated config entries, which is trivial to do and clears up memory ownership by a lot.

123e5963

2018-08-10T18:59:59

config_entries: abstract away reference counting Instead of directly calling `git_atomic_inc` in users of the config entries store, provide a `git_config_entries_incref` function to further decouple the interfaces. Convert the refcount to a `git_refcount` structure while at it.

5a7e0b3c

2018-08-10T18:49:38

config_entries: abstract away iteration over entries The nice thing about our `git_config_iterator` interfaces is that nobody needs to know anything about the implementation details. All that is required is to obtain the iterator via any backend and then use it by executing generic functions. We can thus completely internalize all the implementation details of how to iterate over entries into the config entries store and simply create such an iterator in our config file backend when we want to iterate its entries. This further decouples the config file backend from the config entries store.

60ebc137

2018-08-10T14:53:09

config_entries: abstract away retrieval of config entries The code accessing config entries in the `git_config_entries` structure is still much too intimate with implementation details, directly accessing the maps and handling indices. Provide two new functions to get config entries from the internal map structure to decouple the interfaces and use them in the config file code. The function `git_config_entries_get` will simply look up the entry by name and, in the case of a multi-value, return the last occurrence of that entry. The second function, `git_config_entries_get_unique`, will only return an entry if it is unique and not included via another configuration file. This one is required to properly implement write operations for single entries, as we refuse to write to or delete a single entry if it is not clear which one was meant.

fb8a87da

2018-08-10T14:50:15

config_entries: rename functions and structure The previous commit simply moved all code that is required to handle config entries to a new module without yet adjusting any of the function and structure names to help readability. We now rename things accordingly to have a common "git_config_entries" entries instead of the old "diskfile_entries" one.

04f57d51

2018-08-10T13:33:02

config_entries: pull out implementation of entry store The configuration entry store that is used for configuration files needs to keep track of all entries in two different structures: - a singly linked list is being used to be able to iterate through configuration files in the order they have been found - a string map is being used to efficiently look up configuration entries by their key This store is thus something that may be used by other, future backends as well to abstract away implementation details and iteration over the entries. Pull out the necessary functions from "config_file.c" and moves them into their own "config_entries.c" module. For now, this is simply moving over code without any renames and/or refactorings to help reviewing.

d75bbea1

2018-08-10T14:35:23

config_file: remove unnecessary snapshot indirection The implementation for config file snapshots has an unnecessary redirection from `config_snapshot` to `git_config_file__snapshot`. Inline the call to `git_config_file__snapshot` and remove it.

b944e137

2018-08-10T13:03:33

config: rename "config_file.h" to "config_backend.h" The header "config_file.h" has a list of inline-functions to access the contents of a config backend without directly messing with the struct's function pointers. While all these functions are called "git_config_file_*", they are in fact completely backend-agnostic and don't care whether it is a file or not. Rename all the function to instead be backend-agnostic versions called "git_config_backend_*" and rename the header to match.

1aeff5d7

2018-08-10T12:52:18

config: move function normalizing section names into "config.c" The function `git_config_file_normalize_section` is never being used in any file different than "config.c", but it is implemented in "config_file.c". Move it over and make the symbol static.

f2694635

2018-09-06T14:17:54

config_file: fix quadratic behaviour when adding config multivars In case where we add multiple configuration entries with the same key to a diskfile backend, we always need to iterate the list of this key to find the last entry due to the list being a singly-linked list. This is obviously quadratic behaviour, and this has sure enough been found by oss-fuzz by generating a configuration file with 50k lines, where most of them have the same key. While the issue will not arise with "sane" configuration files, an adversary may trigger it by providing a crafted ".gitmodules" file, which is delivered as part of the repo and also parsed by the configuration parser. The fix is trivial: store a pointer to the last entry of the list in its head. As there are only two locations now where we append to this data structure, mainting this pointer is trivial, too. We can also optimize retrieval of a single value via `config_get`, where we previously had to chase the `next` pointer to find the last entry that was added. Using our configuration file fozzur with a corpus that has a single file with 50000 "-=" lines previously took around 21s. With this optimization the same file scans in about 0.053s, which is a nearly 400-fold improvement. But in most cases with a "normal" amount of same-named keys it's not going to matter anyway.

ec76a1aa

2018-08-05T14:37:08

Add a comment

019409be

2018-08-05T14:25:22

Don't error on missing section, just continue

c4d7fa95

2018-07-22T23:31:19

config_file: Don't crash on options without a section

e1e90dcc

2018-01-09T14:52:34

config_file: avoid free'ing OOM buffers Buffers which ran out of memory will never have any memory attached to them. As such, it is not necessary to call `git_buf_free` if the buffer is out of memory.

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`

6a15f657

2018-02-09T13:02:26

config_file: iterate over keys in the order they were added Currently, all configuration entries were only held in a string map, making iteration order mostly based on the hash of each entry's key. Now that we have extended the `diskfile_entries` structure by a list of config entries, we can effectively iterate through entries in the order they were added, though.

3a82475f

2018-02-09T12:49:45

config_file: add list holding config entries in order of appearance Right now, we only keep all configuration entries in a string map. This is required to efficiently access configuration entries by keys. It has the disadvantage of not being able to iterate through configuration entries in the order they were read, though. Instead, we only iterate through entries in a seemingly random order. Extend `diskfile_entries` by another list holding configuration entries. Like this, we maintain all entries in two data structures and can use the required one based on the current use case.

8c0b0717

2018-02-09T12:32:24

config_file: pass complete entry structure into `append_entry` Currently, we only parse the entry map into `append_entry` to append new configuration entries to it. Instead, though, we can just pass the complete `diskfile_entries` structure into it. This allows us to easily extend `diskfile_entries` by another singly linked list of configuration entries.

eafb8402

2018-02-09T12:29:16

config_file: rename `refcounted_strmap` to `diskfile_entries` The config file parsing code all revolves around the `refcounted_strmap` structure, which is a map of entry names to their respective keys. This naming scheme made grasping the code quite hard, warranting a rename. A good alternative is `diskfile_entries`, making clear that this really only holds all configuration entries. Furthermore, we are about to introduce a new linked list of configuration entries into the configuration file code. This list will be used to iterate over configuration entries in the order they are listed inside of the parsed configuration file. After renaming `refcounted_strmap` to `diskfile_entries`, this struct also becomes the natural target where to add that new list. Like this, data structures holding all entries are neatly contained inside of it.

e3c8462c

2018-02-09T11:50:28

config_file: rename parse_data struct The struct `parse_data` sounds as if it was defined and passed to us from the configuration parser, which is not true. Instead, `parse_data` is specific to the diskfile backend parsing logic. Rename it to `diskfile_parse_state` to make that clearer. This also follows existing naming patterns with the "diskfile" prefix.

18117a6c

2018-02-09T11:43:13

config_file: use new line to declare new variable

b6f88706

2018-02-09T11:39:26

config_file: refactor freeing of config entry lists The interface for freeing config list entries is more tangled than required. Instead of calling `cvar_free` for every list entry in `free_vars`, we now just provide a function `config_entry_list_free`. This function will iterate through all list entries and free the associated configuration entry as well as the list entry itself.

2d1f6676

2018-02-09T11:35:54

config_file: rename cvar_t struct to config_entry_list The `cvar_t` structure is really awkward to grasp, because its name actively hinders discovery of what it actually is. As it is nothing more than a singly-linked list of configuration entries, name rename it to just that: `config_entry_list`.

26cf48fc

2018-02-09T11:35:16

config_file: move include depth into config entry In order to reject writes to included configuration entries, we need to keep track of whether an entry was included via another configuration file or not. This information is being stored in the `cvar` structure, which is a rather weird location, as it is only used to create a list structure of config entries. Move the include depth into the structure `git_config_entry` instead. While this fixes the layering issue, it enables users of libgit2 to access the depth, too.

fcb0d841

2018-02-09T11:19:47

config_file: move cvar handling into `append_entry` The code appending new configuration entries to our current list first allocates the `cvar` structure and then passes it to `append_entry`. As we want to extend `append_entry` to store configuration entries in a map as well as in a list for ordered iteration, we will have to create two `cvar` structures, though. As such, the future change will become much easier when allocation of the `cvar` structure is doen in `append_entry` itself.

dfcd923c

2018-02-09T11:15:32

config_file: remove unused list iteration macros We currently provide a lot of macros for the `cvar_t` structure which are never being used. In fact, the only macro we need is to access the `next` pointer of `cvar_t`, which really does not require a macro at all. Remove all these macros and replace usage of `CVAR_LIST_NEXT(cvar)` with `cvar->next`.

9cd0c6f1

2018-02-28T16:01:16

config: return an error if config_refresh is called on a snapshot Instead of treating it as a no-op, treat it as a programming error and return the same kind of error as if you called to set or delete variables on a snapshot.

2424e64c

2018-02-28T12:06:02

config: harden our use of the backend objects a bit When we create an iterator we don't actually know that we have a live config object and we must instead only rely on the header. We fixed it to use this in a previous commit, but this makes it harder to misuse by converting to use the header object in the typecast. We also guard inside the `config_refresh` function against being given a snapshot (although callers right now do check).

1785de4e

2018-02-28T11:46:17

config: move the level field into the header We use it in a few places where we might have a full object or a snapshot so move it to where we can actually access it.

c1524b2e

2018-02-28T11:33:11

config: move the repository to the diskfile header We pass this around and when creating a new iterator we need to read the repository pointer. Put it in a common place so we can reach it regardless of whether we got a full object or a snapshot.

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`.

42627933

2017-11-04T18:03:26

Merge remote-tracking branch 'upstream/master' into pks/conditional-includes

1475b981

2017-11-04T18:00:56

config: keep the output parameter at the start of the function

94e30d9b

2017-10-30T15:55:18

config: check for OOM when writing

8ec806d7

2017-10-30T06:23:31

config: preserve the original case when writing out new sections and vars For sections we will still use the existing one even if the case disagrees, but the variable always gets written with the case given by the caller.

f7d837c8

2017-05-24T12:12:29

config_file: implement "gitdir/i" conditional Next to the "gitdir" conditional for including other configuration files, there's also a "gitdir/i" conditional. In contrast to the former one, path matching with "gitdir/i" is done case-insensitively. This commit implements the case-insensitive condition.

071b6c06

2017-05-24T11:13:36

config_file: implement conditional "gitdir" includes Upstream git.git has implemented the ability to include other configuration files based on conditions. Right now, this only includes the ability to include a file based on the gitdir-location of the repository the currently parsed configuration file belongs to. This commit implements handling these conditional includes for the case-sensitive "gitdir" condition.

9d7a75be

2017-08-25T19:15:00

config_file: make repo and config path accessible to reader The reader machinery will be extended to handle conditional includes. The only conditions that currently exist all match the against the git directory of the repository the config file belongs to. As such, we need to have access to the repository when reading configuration files to properly handle these conditions. One specialty of thes conditional includes is that the actual pattern may also be a relative pattern starting with "./". In this case, we have to match the pattern against the path relative to the config file which is currently being parsed. So besides the repository, we also have to pass down the path to the current config file that is being parsed.

d5b9d9e9

2017-05-23T10:53:49

config_file: extract function to parse include path The logic inside this function will be required later on, when implementing conditional includes. Extract it into its own function to ease the implementation.

529e873c

2017-05-23T11:51:00

config: pass repository when opening config files Our current configuration logic is completely oblivious of any repository, but only cares for actual file paths. Unfortunately, we are forced to break this assumption by the introduction of conditional includes, which are evaluated in the context of a repository. Right now, only one conditional exists with "gitdir:" -- it will only include the configuration if the current repository's git directory matches the value passed to "gitdir:". To support these conditionals, we have to break our API and make the repository available when opening a configuration file. This commit extends the `open` call of configuration backends to include another repository and adjusts existing code to have it available. This includes the user-visible functions `git_config_add_file_ondisk` and `git_config_add_backend`.

1560b580

2017-08-15T10:35:47

Merge pull request #4288 from pks-t/pks/include-fixups Include fixups

1b329089

2017-05-31T22:27:19

config_file: refuse modifying included variables Modifying variables pulled in by an included file currently succeeds, but it doesn't actually do what one would expect, as refreshing the configuration will cause the values to reappear. As we are currently not really able to support this use case, we will instead just return an error for deleting and setting variables which were included via an include.

28c2cc3d

2017-05-31T16:41:44

config_file: move reader into `config_read` only Right now, we have multiple call sites which initialize a `reader` structure. As the structure is only actually used inside of `config_read`, we can instead just move the reader inside of the `config_read` function. Instead, we can just pass in the configuration file into `config_read`, which eases code readability.

83bcd3a1

2017-05-31T22:45:25

config_file: refresh all files if includes were modified Currently, we only re-parse the top-level configuration file when it has changed itself. This can cause problems when an include is changed, as we were not updating all values correctly. Instead of conditionally reparsing only refreshed files, the logic becomes much clearer and easier to follow if we always re-parse the top-level configuration file when either the file itself or one of its included configuration files has changed on disk. This commit implements this logic. Note that this might impact performance in some cases, as we need to re-read all configuration files whenever any of the included files changed. It could increase performance to just re-parse include files which have actually changed, but this would compromise maintainability of the code without much gain. The only case where we will gain anything is when we actually use includes and when only these includes are updated, which will probably be quite an unusual scenario to actually be worthwhile to optimize.

56a7a264

2017-05-31T14:50:40

config_file: remove unused backend field from parse data The backend passed to `config_read` is never actually used anymore, so we can remove it from the function and the `parse_data` structure.

3a7f7a6e

2017-05-31T14:43:46

config_file: pass reader directly to callbacks Previously, the callbacks passed to `config_parse` got the reader via a pointer to a pointer. This allowed the callbacks to update the callers `reader` variable when the array holding it has been reallocated. As the array is no longer present, we can simply the code by making the reader a simple pointer.

73df75d8

2017-05-31T14:34:48

config_file: refactor include handling Current code for configuration files uses the `reader` structure to parse configuration files and store additional metadata like the file's path and checksum. These structures are stored within an array in the backend itself, which causes multiple problems. First, it does not make sense to keep around the file's contents with the backend itself. While this data is usually free'd before being added to the backend, this brings along somewhat intricate lifecycle problems. A better solution would be to store only the file paths as well as the checksum of the currently parsed content only. The second problem is that the `reader` structures are stored inside an array. When re-parsing configuration files due to changed contents, we may cause this array to be reallocated, requiring us to update pointers hold by callers. Furthermore, we do not keep track of includes which are already associated to a reader inside of this array. This causes us to add readers multiple times to the backend, e.g. in the scenario of refreshing configurations. This commit fixes these shortcomings. We introduce a split between the parsing data and the configuration file's metadata. The `reader` will now only hold the file's contents and the parser state and the new `config_file` structure holds the file's path and checksum. Furthermore, the new structure is a recursive structure in that it will also hold references to the files it directly includes. The diskfile is changed to only store the top-level configuration file. These changes allow us further refactorings and greatly simplify understanding the code.

0c7f49dd

2017-06-30T13:39:01

Make sure to always include "common.h" first Next to including several files, our "common.h" header also declares various macros which are then used throughout the project. As such, we have to make sure to always include this file first in all implementation files. Otherwise, we might encounter problems or even silent behavioural differences due to macros or defines not being defined as they should be. So in fact, our header and implementation files should make sure to always include "common.h" first. This commit does so by establishing a common include pattern. Header files inside of "src" will now always include "common.h" as its first other file, separated by a newline from all the other includes to make it stand out as special. There are two cases for the implementation files. If they do have a matching header file, they will always include this one first, leading to "common.h" being transitively included as first file. If they do not have a matching header file, they instead include "common.h" as first file themselves. This fixes the outlined problems and will become our standard practice for header and source files inside of the "src/" from now on.

a693b873

2017-06-07T10:20:44

buffer: use `git_buf_init` with length The `git_buf_init` function has an optional length parameter, which will cause the buffer to be initialized and allocated in one step. This can be used instead of static initialization with `GIT_BUF_INIT` followed by a `git_buf_grow`. This patch does so for two functions where it is applicable.

a1023a43

2017-05-20T17:18:07

Merge pull request #4179 from libgit2/ethomson/expand_tilde Introduce home directory expansion function for config files, attribute files

4467aeac

2017-03-28T09:00:48

config_file: handle errors other than OOM while parsing section headers The current code in `parse_section_header_ext` is only prepared to properly handle out-of-memory conditions for the `git_buf` structure. While very unlikely and probably caused by a programming error, it is also possible to run into error conditions other than out-of-memory previous to reaching the actual parsing loop. In these cases, we will run into undefined behavior as the `rpos` variable is only initialized after these triggerable errors, but we use it in the cleanup-routine. Fix the issue by unifying the function's cleanup code with an `end_error` section, which will not use the `rpos` variable.

29aef948

2017-03-23T11:59:06

config, attrcache: don't fallback to dirs literally named `~` The config and attrcache file reading code would attempt to load a file in a home directory by expanding the `~` and looking for the file, using `git_sysdir_find_global_file`. If the file was not found, the error handling would look for the literal path, eg `~/filename.txt`. Use the new `git_config_expand_global_file` instead, which allows us to get the path to the file separately, when the path is prefixed with `~/`, and fail with a not found error without falling back to looking for the literal path.

301dc26a

2016-06-20T13:15:35

fix error when including a missing config file relative to the home directory

2cf48e13

2017-03-20T09:34:41

config_file: check if section header buffer runs out of memory While parsing section headers, we use a buffer to store the actual section name. We do not check though if the buffer runs out of memory at any stage. Do so.

13c3bc9a

2017-01-27T14:32:23

strmap: remove GIT__USE_STRMAP macro

73028af8

2017-01-27T14:20:24

khash: avoid using macro magic to get return address

909d5494

2016-12-29T12:25:15

giterr_set: consistent error messages Error messages should be sentence fragments, and therefore: 1. Should not begin with a capital letter, 2. Should not conclude with punctuation, and 3. Should not end a sentence and begin a new one

ab96ca55

2016-10-06T13:15:31

Make sure we use the `C` locale for `regcomp` on macOS.

2f0450f4

2016-03-29T03:26:43

Merge pull request #3712 from ethomson/config_duplicate_section config: don't write duplicate section

e25e1ca1

2016-03-28T11:13:51

config: don't write section header if we're in it If we hit the EOF while trying to write a new value, it may be that we're already in the section that we were looking for. If so, do not write a (duplicate) section header, just write the value.

6f09911c

2016-03-21T21:10:26

config: don't special-case multivars that don't exist yet This special-casing ignores that we might have a locked file, so the hashtable does not represent the contents of the file we want to write. This causes multivar writes to overwrite entries instead of add to them when under lock. There is no need for this as the normal code-path will write to the file just fine, so simply get rid of it.

77394a27

2016-03-14T19:15:20

Merge pull request #3677 from pks-t/pks/coverity-fixes-round7 Coverity fixes round 7

836447e5

2016-03-10T16:52:09

config_file: handle error when trying to lock strmap Accessing the current values map is handled through the `refcounder_strmap_take` function, which first acquires a mutex before accessing its values. While this assures everybody is trying to access the values with the mutex only we do not check if the locking actually succeeds. Fix the issue by checking if acquiring the lock succeeds and returning `NULL` if we encounter an error. Adjust callers.

e126bc95

2016-03-01T14:40:17

config_file: handle missing quotation marks in section header When parsing a section header we expect something along the format of '[section "subsection"]'. When a section is mal-formated and is entirely missing its quotation marks we catch this case by observing that `strchr(line, '"') - strrchr(line, '"') = NULL - NULL = 0` and error out. Unfortunately, the error message is misleading though, as we state that we are missing the closing quotation mark while we in fact miss both quotation marks. Improve the error message by explicitly checking if the first quotation mark could be found and, if not, stating that quotation marks are completely missing.

eb597799

2015-10-29T21:12:37

filebuf: use a checksum to detect file changes Instead of relying on the size and timestamp, which can hide changes performed in the same second, hash the file content's when we care about detecting changes.

cd677b8f

2015-09-18T12:28:05

config: buffer comments to match git's variable-adding When there is a comment at the end of a section, git keeps it there, while we write the new variable right at the end. Keep comments buffered and dump them when we're going to output a variable or section, or reach EOF. This puts us in line with the config files which git produces.

b1667039

2015-06-01T19:17:03

config: implement basic transactional support When a configuration file is locked, any updates made to it will be done to the in-memory copy of the file. This allows for multiple updates to happen while we hold the lock, preventing races during complex config-file manipulation.

3ce9e4d2

2015-06-01T08:45:15

config: write the modified file to memory Instead of writing into the filebuf directly, make the functions to write the modified config file write into a buffer which can then be dumped into the lockfile for committing. This allows us to re-use the same code for modifying a locked configuration, as we can simply skip the last step of dumping the data to disk.

75a4636f

2015-05-29T16:56:38

git__tolower: a tolower() that isn't dumb Some brain damaged tolower() implementations appear to want to take the locale into account, and this may require taking some insanely aggressive lock on the locale and slowing down what should be the most trivial of trivial calls for people who just want to downcase ASCII.

b162d97a

2015-05-05T09:47:16

config: plug a couple of leaks

63c0cc65

2015-04-27T16:29:00

config: cleanup some now-unused variables

9c26de0f

2015-04-27T15:38:44

config: lock the file for write before reading When writing a configuration file, we want to take a lock on the new file (eg, `config.lock`) before opening the configuration file (`config`) for reading so that we can prevent somebody from changing the contents underneath us.

2a950c94

2015-04-27T10:43:50

config: write existing lines as-is when rewriting When updating a configuration file, we want to copy the old data from the file to preserve comments and funny whitespace, instead of writing it in some "canonical" format. Thus, we keep a pointer to the start of the line and the line length to preserve these things we don't care to rewrite.

bf99390e

2015-04-23T16:54:36

config: examine whole file when writing Previously we would try to be clever when writing the configuration file and try to stop parsing (and simply copy the rest of the old file) when we either found the value we were trying to write, or when we left the section that value was in, the assumption being that there was no more work to do. Regrettably, you can have another section with the same name later in the file, and we must cope with that gracefully, thus we read the whole file in order to write a new file. Now, writing a file looks even more than reading. Pull the config parsing out into its own function that can be used by both reading and writing the configuration.

d369d71f

2015-04-21T17:18:35

config: peek returns '\n' on EOF; handle in write

2c8c00c6

2015-04-21T12:52:29

config: validate config keys

9a810c5e

2015-04-16T15:32:16

git_config_delete: search until last section. If git_config_delete is to work properly in the presence of duplicate section headers, it cannot stop searching at the end of the first matching section, as there may be another matching section later. When config_write is used for deletion (value = NULL), it may only terminate when the desired key is found or there are no sections left to parse.

e009a705

2015-04-20T00:22:20

config_file: comment char can be invalid escape Don't assume that comment chars are comment chars, they may be (an attempt to be escaped). If so, \; is not a valid escape sequence, complain.

7f2e61f3

2015-04-19T23:55:02

config_file: parse multilines generously Combine unquoting and multiline detection to avoid ambiguity when parsing.

129022ee

2015-04-10T09:36:38

Fix checking of return value for regcomp. The regcomp function returns a non-zero value if compilation of a regular expression fails. In most places we only check for negative values, but positive values indicate an error, as well. Fix this tree-wide, fixing a segmentation fault when calling git_config_iterator_glob_new with an invalid regexp.

9a97f49e

2014-12-21T15:31:03

config: borrow refcounted references This changes the get_entry() method to return a refcounted version of the config entry, which you have to free when you're done. This allows us to avoid freeing the memory in which the entry is stored on a refresh, which may happen at any time for a live config. For this reason, get_string() has been forbidden on live configs and a new function get_string_buf() has been added, which stores the string in a git_buf which the user then owns. The functions which parse the string value takea advantage of the borrowing to parse safely and then release the entry.

c8e02b87

2015-02-15T21:07:05

Remove extra semicolon outside of a function Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.

a7fa970f

2015-02-15T05:13:50

Merge pull request #2895 from ethomson/alloc_overflow allocations: test for overflow of requested size

f1453c59

2015-02-12T12:19:37

Make our overflow check look more like gcc/clang's Make our overflow checking look more like gcc and clang's, so that we can substitute it out with the compiler instrinsics on platforms that support it. This means dropping the ability to pass `NULL` as an out parameter. As a result, the macros also get updated to reflect this as well.

2884cc42

2015-02-11T09:39:38

overflow checking: don't make callers set oom Have the ALLOC_OVERFLOW testing macros also simply set_oom in the case where a computation would overflow, so that callers don't need to.

392702ee

2015-02-09T23:41:13

allocations: test for overflow of requested size Introduce some helper macros to test integer overflow from arithmetic and set error message appropriately.

17136538

2015-02-05T23:39:59

Reinit `reader` pointer after reading included config file Fixes #2869. If included file includes more files, it may reallocate cfg_file->readers, hence invalidate not only `r` pointer, but `result` pointer as well.

6f73e026

2014-12-24T11:42:50

Plug some leaks

b874629b

2014-12-04T21:06:59

Spelling fixes

ebc13b2b

2014-11-02T19:16:49

Clean up issues include.path issues found during code review. * Error-handling is cleaned up to only let a file-not-found error through, not other sorts of errors. And when a file-not-found error happens, we clean up the error. * Test now checks that file-not-found introduces no error. And other minor cleanups.

727ae380

2014-11-01T11:21:45

Make config reading continue after hitting a missing include file. For example, if you have [include] path = foo and foo didn't exist, git_config_open_ondisk() would just give up on the rest of the file. Now it ignores the unresolved include without error and continues reading the rest of the file.

thodg/libgit2/src/config_file.c

src/config_file.c

Log