src/config_file.h


Log

Author Commit Date CI Message
Edward Thomson abb04caa 2018-02-01T15:55:48 consistent header guards use consistent names for the #include / #define header guard pattern.
Patrick Steinhardt 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`.
Patrick Steinhardt 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.
Patrick Steinhardt 64244131 2017-04-25T12:59:48 config_file: add missing include for `git_config_backend` The config_file.h header provides some inline declarations accessing the `git_config_backend`, but misses its declaration. Add the missing include for "git2/sys/config.h" to add it.
Carlos Martín Nieto 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.
Carlos Martín Nieto 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.
Russell Belfer db0e7878 2014-03-28T16:50:49 Make submodule refresh a bit smarter This makes submodule cache refresh actually look at the timestamps from the data sources for submodules and reload as needed if they have changed since the last refresh.
Nico von Geyso a603c191 2013-03-18T21:02:36 replaced foreach() with non callback based iterations in git_config_backend new functions in struct git_config_backend: * iterator_new(...) * iterator_free(...) * next(...) The old callback based foreach style can still be used with `git_config_backend_foreach_match`
Russell Belfer 1e7799e8 2013-01-29T12:15:18 Implement config key validation rules This is a new implementation of core git's config key checking rules that prevents non-alphanumeric characters (and '-') for the top-level section and key names inside of config files. This also validates the target section name when renaming sections.
Edward Thomson 359fc2d2 2013-01-08T17:07:25 update copyrights
Ben Straub 54b2a37a 2012-11-20T16:02:25 Clean up config.h
yorah a1abe66a 2012-09-10T12:11:02 Add config level support in the config API Added `struct git_config_entry`: a git_config_entry contains the key, the value, and the config file level from which a config element was found. Added `git_config_open_level`: build a single-level focused config object from a multi-level one. We are now storing `git_config_entry`s in the khash of the config_file
Russell Belfer aa13bf05 2012-08-02T13:00:58 Major submodule rewrite This replaces the old submodule API with a new extended API that supports most of the things that can be done with `git submodule`.
Russell Belfer b3ff1dab 2012-07-10T15:22:39 Adding git_config_foreach_match() iteration fn Adding a new config iteration function that let's you iterate over just the config entries that match a particular regular expression. The old foreach becomes a simple use of this with an empty pattern. This also fixes an apparent bug in the existing `git_config_foreach` where returning a non-zero value from the iteration callback was not correctly aborting the iteration and the returned value was not being propogated back to the caller of foreach. Added to tests to cover all these changes.
Russell Belfer bfc9ca59 2012-03-28T16:45:36 Added submodule API and use in status When processing status for a newly checked out repo, it is possible that there will be submodules that have not yet been initialized. The only way to distinguish these from untracked directories is to have some knowledge of submodules. This commit adds a new submodule API which, given a name or path, can determine if it appears to be a submodule and can give information about the submodule.