- 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
-