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.
We might modify caches due to us trying to load the configuration to figure out what kinds of filesystem protections we should have.
If the we decide that the "name" of the submodule (i.e. its path inside `.git/modules/`) is trying to escape that directory or otherwise trick us, we ignore the configuration for that submodule. This leaves us with a half-configured submodule when looking it up by path, but it's the same result as if the configuration really were missing. The name check is potentially more strict than it needs to be, but it lets us re-use the check we're doing for the checkout. The function that encapsulates this logic is ready to be exported but we don't want to do that in a security release so it remains internal for now.
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.
Added `git_repository_submodule_cache_all` to initialze a cache of submodules on the repository so that operations looking up N submodules are O(N) and not O(N^2). Added a `git_repository_submodule_cache_clear` function to remove the cache. Also optimized the function that loads all submodules as it was itself O(N^2) w.r.t the number of submodules, having to loop through the `.gitmodules` file once per submodule. I changed it to process the `.gitmodules` file once, into a map. Signed-off-by: David Turner <dturner@twosigma.com>
We currently do not handle those enum values which require us to set "true" or unset variables in all cases. Use a common function which does understand this by looking at our mapping directly.
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.
This is used by the submodule in order to figure out if the index has changed since it last read it. Using a timestamp is racy, so let's make it use the checksum, just like we now do for reloading the index itself.
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.
This takes the old submodule cache which was just a git_strmap and makes a real git_submodule_cache object that can contain other things like a lock and timestamp-ish data to control refreshing of submodule info.