- 31 Oct, 2017 1 commit
-
-
We put our repository in the temporary directory which makes macOS map the path into a virtual path. `realpath(3)` can resolve it and we do so during repository opening, but that makes its path have a different prefix from the sandbox path clar thinks we have. Resolve the sandbox path before putting it into the test config files so the paths match as expected.
Carlos Martín Nieto committed
-
- 30 Oct, 2017 1 commit
-
-
While most parts of a configuration key are case-insensitive, we should still be case-preserving and write down whatever string the caller provided.
Carlos Martín Nieto committed
-
- 09 Oct, 2017 3 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed -
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 committed
-
- 15 Jul, 2017 4 commits
-
-
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed -
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.
Patrick Steinhardt committed -
Patrick Steinhardt committed
-
- 05 Jul, 2017 1 commit
-
-
On systems where we pull in our distributed version of the regex library, all tests in config::readonly fail. This error is actually quite interesting: the test suite is unable to find the declaration of `git_path_exists` and assumes it has a signature of `int git_path_exists(const char *)`. But actually, it has a `bool` return value. Due to this confusion, some wrong conversion is done by the compiler and the `cl_assert(!git_path_exists("file"))` checks erroneously fail, even when the function does in fact return the correct value. The error is actually introduced by 56893bb9 (cmake: consistently use TARGET_INCLUDE_DIRECTORIES if available, 2017-06-28), unfortunately introduced by myself. Due to the delayed addition of include directories, we will now find the "config.h" header inside of the "deps/regex" directory instead of inside the "src/" directory, where it should be. As such, we are missing definitions for the `git_config_file__ondisk` and `git_path_exists` symbols. The correct fix here would be to fix the order in which include search directories are added. But due to the current restructuring of CMakeBuild.txt, I'm refraining from doing so and delay the proper fix a bit. Instead, we paper over the issue by explicitly including "path.h" to fix its prototype. This ignores the issue that `git_config_file__ondisk` is undeclared, as its signature is correctly identified by the compiler.
Patrick Steinhardt committed
-
- 26 Apr, 2017 1 commit
-
-
Patrick Steinhardt committed
-
- 23 Mar, 2017 2 commits
-
-
Sanitize the home directory to ensure that we do not accidentally locate a file called `~/.nonexistentfile`.
Edward Thomson committed -
Sim Domingo committed
-
- 31 Mar, 2016 1 commit
-
-
Edward Thomson committed
-
- 28 Mar, 2016 2 commits
-
-
Edward Thomson committed
-
We should notice that we are in the correct section to add. This is a cosmetic bug, since replacing any of these settings does work.
Carlos Martín Nieto committed
-
- 21 Mar, 2016 1 commit
-
-
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.
Carlos Martín Nieto committed
-
- 24 Nov, 2015 2 commits
-
-
Patrick Steinhardt committed
-
Patrick Steinhardt committed
-
- 17 Nov, 2015 1 commit
-
-
Query the `GIT_CONFIG_LEVEL_PROGRAMDATA` location when setting it up for tests, in case the test runner has sandboxed it.
Edward Thomson committed
-
- 30 Oct, 2015 1 commit
-
-
We currently use the timestamp in order to decide whether a config file has changed since we last read it. This scheme falls down if the file is written twice within the same second, as we fail to detect the file change after the first read in that second.
Carlos Martín Nieto committed
-
- 21 Oct, 2015 1 commit
-
-
This is where portable git stores the global configuration which we can use to adhere to it even though git isn't quite installed on the system.
Carlos Martín Nieto committed
-
- 18 Sep, 2015 1 commit
-
-
Linquize committed
-
- 17 Sep, 2015 1 commit
-
-
Untangle git_futils_mkdir from git_futils_mkdir_ext - the latter assumes that we own everything beneath the base, as if it were being called with a base of the repository or working directory, and is tailored towards checkout and ensuring that there is no bogosity beneath the base that must be cleaned up. This is (at best) slow and (at worst) unsafe in the larger context of a filesystem where we do not own things and cannot do things like unlink symlinks that are in our way.
Edward Thomson committed
-
- 13 Sep, 2015 1 commit
-
-
The config is not owned by the transaction, so please don’t free it.
Arthur Schreiber committed
-
- 12 Aug, 2015 3 commits
-
-
This makes the API for commiting or discarding changes the same as for references.
Carlos Martín Nieto committed -
This lock/unlock pair allows for the cller to lock a configuration file to avoid concurrent operations. It also allows for a transactional approach to updating a configuration file. If multiple updates must be made atomically, they can be done while the config is locked.
Carlos Martín Nieto committed -
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 committed
-
- 04 May, 2015 7 commits
-
-
If a multivar exists within two sections (of the same name) then they should both be updated in a `set_multivar`. Ensure that this is the case.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
Add a test that exposes a bug in config_write. It is valid to have multiple separate headers for the same config section, but config_write will exit after finding the first matching section in certain situations. This test proves that config_write will duplicate a variable that already exists instead of overwriting it if the variable is defined under a duplicate section header.
Ryan Roden-Corrent committed -
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.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
- 23 Apr, 2015 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 21 Apr, 2015 2 commits
-
-
Instead of using a config file in resources, include the config file content to be tested directly in the test.
Ryan Roden-Corrent committed -
Add a unittest to validate bug #3043, where a duplicate empty config header could cause deletion of a config entry to fail silently. The bug is currently unresolved and this test will fail.
Ryan Roden-Corrent committed
-
- 20 Apr, 2015 1 commit
-
-
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.
Edward Thomson committed
-