- 23 Feb, 2022 1 commit
-
-
Like we want to separate libgit2 and utility source code, we want to separate libgit2 and utility tests. Start by moving all the tests into libgit2.
Edward Thomson committed
-
- 05 Jan, 2022 1 commit
-
-
Dimitris Apostolou committed
-
- 09 Oct, 2017 1 commit
-
-
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
-
- 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
-
- 18 Apr, 2014 1 commit
-
-
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.
Carlos Martín Nieto committed
-
- 14 Nov, 2013 1 commit
-
-
Ben Straub committed
-
- 31 Oct, 2013 1 commit
-
-
At some moment git_config_delete_entry lost the ability to delete one entry of a multivar configuration. The moment you had more than one fetch or push ref spec for a remote you will not be able to save that remote anymore. The changes in network::remote::remotes::save show that problem. I needed to create a new git_config_delete_multivar because I was not able to remove one or several entries of a multivar config with the current API. Several tries modifying how git_config_set_multivar(..., NULL) behaved were not successful. git_config_delete_multivar is very similar to git_config_set_multivar, and delegates into config_delete_multivar of config_file. This function search for the cvar_t that will be deleted, storing them in a temporal array, and rebuilding the linked list. After calling config_write to delete the entries, the cvar_t stored in the temporal array are freed. There is a little fix in config_write, it avoids an infinite loop when using a regular expression (case for the multivars). This error was found by the test network::remote::remotes::tagopt.
Daniel Rodríguez Troitiño committed
-
- 13 Aug, 2013 1 commit
-
-
Build it on top of the normal iterator instead, which lets use re-use a lot of code.
Carlos Martín Nieto committed
-
- 08 Aug, 2013 3 commits
-
-
Make it look like the refs iterator API.
Carlos Martín Nieto committed -
Implement the foreach version as a wrapper around the iterator.
Carlos Martín Nieto committed -
The plain function will return an iterator, so move this one out of the way.
Carlos Martín Nieto committed
-
- 09 Jul, 2013 1 commit
-
-
The old tests didn't try failing lookups or lookups across multiple config files with some having the pattern and some not having it.
Russell Belfer committed
-
- 20 Apr, 2013 1 commit
-
-
Adding a multivar when there are no variables with that name set should set the variable instead of failing.
Carlos Martín Nieto committed
-
- 23 Oct, 2012 1 commit
-
-
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
yorah committed
-
- 17 May, 2012 1 commit
-
-
Vicent Martí committed
-
- 01 Apr, 2012 1 commit
-
-
Ben Straub committed
-
- 02 Mar, 2012 2 commits
-
-
This clears up the memory leaks that valgrind seems to find on my machine.
Russell Belfer committed -
It turns out that commit 31e9cfc4cbcaf1b38cdd3dbe3282a8f57e5366a5 did not fix the GIT_USUSED behavior on all platforms. This commit walks through and really cleans things up more thoroughly, getting rid of the unnecessary stuff. To remove the use of some GIT_UNUSED, I ended up adding a couple of new iterators for hashtables that allow you to iterator just over keys or just over values. In making this change, I found a bug in the clar tests (where we were doing *count++ but meant to do (*count)++ to increment the value). I fixed that but then found the test failing because it was not really using an empty repo. So, I took some of the code that I wrote for iterator testing and moved it to clar_helpers.c, then made use of that to make it easier to open fixtures on a per test basis even within a single test file.
Russell Belfer committed
-
- 25 Feb, 2012 1 commit
-
-
Carlos Martín Nieto committed
-
- 17 Feb, 2012 3 commits
-
-
Carlos Martín Nieto committed
-
Carlos Martín Nieto committed
-
Carlos Martín Nieto committed
-