|
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.
|
|
|
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.
|
|
|
d49b1365
|
2018-08-10T19:01:37
|
|
config_entries: internalize structure declarations
Access to the config entries is now completely done via the modules
function interface and no caller messes with the struct's internals. We
can thus completely move the structure declarations into the
implementation file so that nobody even has a chance to mess with the
members.
|
|
|
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.
|