kmx git

Commit	Date	Message
ecf4f33a	2018-02-08T11:14:48	Convert usage of `git_buf_free` to new `git_buf_dispose`
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`.
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.
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.
55cb4999	2014-10-23T19:05:02	config: remove the refresh function and backend field We have been refreshing on read and write for a while now, so git_config_refresh() is at best a no-op, and might just end up wasting cycles.
ad5adacb	2014-10-21T09:29:45	Patch from @carlosmn to refresh the parent config before snapshotting.
0a641647	2014-10-04T23:27:06	config: Fix multiple trailing spaces before comments not completely trimmed
9dac1f95	2014-08-09T10:56:50	config: a multiline var can start immediately In the check for multiline, we traverse the backslashes from the end backwards and int the end assert that we haven't gone past the beginning of the line. We make sure of this in the loop condition, but we also check in the return value. However, for certain configurations, a line in a multiline variable might be empty to aid formatting. In that case, 'end' == 'start', since we ended up looking at the first char which made it a multiline. There is no need for the (end > start) check in the return, since the loop guarantees we won't go further back than the first char in the line, and we do accept the first char to be the final backslash. This fixes #2483.
991dab2d	2014-07-16T21:09:53	Make sure \n is at the end of config file before a new section is written
4af0ef96	2014-05-15T11:09:49	Fix mutex init/free in config_file.c
a37aa82e	2014-05-13T15:54:23	Some coverity inspired cleanups
b1914c36	2014-05-12T10:24:46	Minor fixes for warnings and error propagation
2280b388	2014-04-09T13:17:51	config: share the strmap on snapshot Now that our strmap is no longer modified but replaced, we can use the same strmap for the snapshot's values and it will be freed when we don't need it anymore.
4b99b8f5	2014-04-09T13:08:01	config: refcount the values map This is mostly groundwork to let us re-use the map in the snapshots.
8c1f4ab4	2014-04-09T12:26:53	config: refresh on delete When we delete an entry, we also want to refresh the configuration to catch any changes that happened externally. This allows us to simplify the logic, as we no longer need to delete these variables internally. The whole state will be refreshed and the deleted entries won't be there.
523032cd	2014-03-31T09:58:44	config: refresh before reading a value With the isolation of complex reads, we can now try to refresh the on-disk file before reading a value from it. This changes the semantics a bit, as before we could be sure that a string we got from the configuration was valid until we wrote or refreshed. This is no longer the case, as a read can also invalidate the pointer.
eaf37034	2014-03-31T08:53:56	config: refresh the values on write When writing out, parse the resulting file instead of adding or replacing the value locally. This has the effect of reading external changes as well.
0500a1ef	2014-03-31T08:32:45	config: use a snapshot for the iterator
bd95f836	2014-03-31T08:08:17	config: split out the refresh step This will be used by the writing commands in a later step.
c047317e	2014-03-18T17:54:32	config: make refresh atomic Current code sets the active map to a new one and builds it whilst it's active. This is a race condition with someone else trying to access the same config. Instead, let's build up our new map and swap the active and new one.
55ebd7d3	2014-03-13T17:11:34	config: implement config snapshotting In order to have consistent views of the config files for remotes, submodules et al. and a configuration that represents what is currently stored on-disk, we need a way to provide a view of the configuration that does not change. The goal here is to provide the snapshotting part by creating a read-only copy of the state of the configuration at a particular point in time, which does not change when a repository's main config changes.
40ed4990	2014-02-11T14:45:37	Add diff threading tests and attr file cache locks This adds a basic test of doing simultaneous diffs on multiple threads and adds basic locking for the attr file cache because that was the immediate problem that arose from these tests.
83634d38	2014-02-24T17:43:10	Move system directory cache out of utils
a8e4cb11	2014-01-13T22:12:17	Fix a memory leak in `config_parse`.
6014b7b5	2013-12-30T18:08:04	Fixed a compile error in VS2013.
9f77b3f6	2013-11-25T14:21:34	Add config read fns with controlled error behavior This adds `git_config__lookup_entry` which will look up a key in a config and return either the entry or NULL if the key was not present. Optionally, it can either suppress all errors or can return them (although not finding the key is not an error for this function). Unlike other accessors, this does not normalize the config key string, so it must only be used when the key is known to be in normalized form (i.e. all lower-case before the first dot and after the last dot, with no invalid characters). This also adds three high-level helper functions to look up config values with no errors and a fallback value. The three functions are for string, bool, and int values, and will resort to the fallback value for any error that arises. They are: * `git_config__get_string_force` * `git_config__get_bool_force` * `git_config__get_int_force` None of them normalize the config `key` either, so they can only be used for internal cases where the key is known to be in normal format.

ecf4f33a

2018-02-08T11:14:48

Convert usage of `git_buf_free` to new `git_buf_dispose`

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

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.

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.

55cb4999

2014-10-23T19:05:02

config: remove the refresh function and backend field We have been refreshing on read and write for a while now, so git_config_refresh() is at best a no-op, and might just end up wasting cycles.

ad5adacb

2014-10-21T09:29:45

Patch from @carlosmn to refresh the parent config before snapshotting.

0a641647

2014-10-04T23:27:06

config: Fix multiple trailing spaces before comments not completely trimmed

9dac1f95

2014-08-09T10:56:50

config: a multiline var can start immediately In the check for multiline, we traverse the backslashes from the end backwards and int the end assert that we haven't gone past the beginning of the line. We make sure of this in the loop condition, but we also check in the return value. However, for certain configurations, a line in a multiline variable might be empty to aid formatting. In that case, 'end' == 'start', since we ended up looking at the first char which made it a multiline. There is no need for the (end > start) check in the return, since the loop guarantees we won't go further back than the first char in the line, and we do accept the first char to be the final backslash. This fixes #2483.

991dab2d

2014-07-16T21:09:53

Make sure \n is at the end of config file before a new section is written

4af0ef96

2014-05-15T11:09:49

Fix mutex init/free in config_file.c

a37aa82e

2014-05-13T15:54:23

Some coverity inspired cleanups

b1914c36

2014-05-12T10:24:46

Minor fixes for warnings and error propagation

2280b388

2014-04-09T13:17:51

config: share the strmap on snapshot Now that our strmap is no longer modified but replaced, we can use the same strmap for the snapshot's values and it will be freed when we don't need it anymore.

4b99b8f5

2014-04-09T13:08:01

config: refcount the values map This is mostly groundwork to let us re-use the map in the snapshots.

8c1f4ab4

2014-04-09T12:26:53

config: refresh on delete When we delete an entry, we also want to refresh the configuration to catch any changes that happened externally. This allows us to simplify the logic, as we no longer need to delete these variables internally. The whole state will be refreshed and the deleted entries won't be there.

523032cd

2014-03-31T09:58:44

config: refresh before reading a value With the isolation of complex reads, we can now try to refresh the on-disk file before reading a value from it. This changes the semantics a bit, as before we could be sure that a string we got from the configuration was valid until we wrote or refreshed. This is no longer the case, as a read can also invalidate the pointer.

eaf37034

2014-03-31T08:53:56

config: refresh the values on write When writing out, parse the resulting file instead of adding or replacing the value locally. This has the effect of reading external changes as well.

0500a1ef

2014-03-31T08:32:45

config: use a snapshot for the iterator

bd95f836

2014-03-31T08:08:17

config: split out the refresh step This will be used by the writing commands in a later step.

c047317e

2014-03-18T17:54:32

config: make refresh atomic Current code sets the active map to a new one and builds it whilst it's active. This is a race condition with someone else trying to access the same config. Instead, let's build up our new map and swap the active and new one.

55ebd7d3

2014-03-13T17:11:34

config: implement config snapshotting In order to have consistent views of the config files for remotes, submodules et al. and a configuration that represents what is currently stored on-disk, we need a way to provide a view of the configuration that does not change. The goal here is to provide the snapshotting part by creating a read-only copy of the state of the configuration at a particular point in time, which does not change when a repository's main config changes.

40ed4990

2014-02-11T14:45:37

Add diff threading tests and attr file cache locks This adds a basic test of doing simultaneous diffs on multiple threads and adds basic locking for the attr file cache because that was the immediate problem that arose from these tests.

83634d38

2014-02-24T17:43:10

Move system directory cache out of utils

a8e4cb11

2014-01-13T22:12:17

Fix a memory leak in `config_parse`.

6014b7b5

2013-12-30T18:08:04

Fixed a compile error in VS2013.

9f77b3f6

2013-11-25T14:21:34

Add config read fns with controlled error behavior This adds `git_config__lookup_entry` which will look up a key in a config and return either the entry or NULL if the key was not present. Optionally, it can either suppress all errors or can return them (although not finding the key is not an error for this function). Unlike other accessors, this does not normalize the config key string, so it must only be used when the key is known to be in normalized form (i.e. all lower-case before the first dot and after the last dot, with no invalid characters). This also adds three high-level helper functions to look up config values with no errors and a fallback value. The three functions are for string, bool, and int values, and will resort to the fallback value for any error that arises. They are: * `git_config__get_string_force` * `git_config__get_bool_force` * `git_config__get_int_force` None of them normalize the config `key` either, so they can only be used for internal cases where the key is known to be in normal format.

thodg/libgit2/src/config_file.c

src/config_file.c

Log