- 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
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 20 Jul, 2019 1 commit
-
-
Our file utils functions all have a "futils" prefix, e.g. `git_futils_touch`. One would thus naturally guess that their definitions and implementation would live in files "futils.h" and "futils.c", respectively, but in fact they live in "fileops.h". Rename the files to match expectations.
Patrick Steinhardt committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 01 Jul, 2015 1 commit
-
-
The function was removed, but its declaration and changelog entry about its removal were forgotten. The comment in the test doesn't make any sense as the function doesn't exist anymore, so get rid of it as well.
Carlos Martín Nieto committed
-
- 22 Jun, 2015 1 commit
-
-
Having this cache and giving them out goes against our multithreading guarantees and it makes it impossible to use submodules in a multi-threaded environment, as any thread can ask for a refresh which may reallocate some string in the submodule struct which we've accessed in a different one via a getter. This makes the submodules behave more like remotes, where each object is created upon request and not shared except explicitly by the user. This means that some tests won't pass yet, as they assume they can affect the submodule objects in the cache and that will affect later operations.
Carlos Martín Nieto committed
-
- 01 Apr, 2014 2 commits
-
-
With the new submodule cache validity checks, we generally don't need to call git_submodule_reload_all to have up-to-date submodule data. Some tests are still calling it where I want to actually test that it can be called safely and doesn't break anything, but mostly it is not needed. This also expands some of the existing submodule tests to cover some variants on the behavior that was already being tested.
Russell Belfer committed -
Wrote tests that try adding, removing, and updating the name of submodules which showed a number of problems with how we account for changes when incrementally updating the submodule info. Most of these issues didn't exist before because reloading would always blow away the old submodule data.
Russell Belfer committed
-
- 26 Mar, 2014 1 commit
-
-
The reload_all call could end up dereferencing a NULL pointer if there was an error while attempting to load the submodules config data (i.e. invalid content in the gitmodules file). This fixes it.
Russell Belfer committed
-