- 23 Mar, 2022 5 commits
-
-
gcc (mingw) warns when you cast the result of `GetProcAddress`; cast the results to `void *` before casting them to the actual result.
Edward Thomson committed -
When GIT_SHA1_WIN32 or GIT_SHA256_WIN32 is used, ensure that we test both CryptoNG ("cng") and CryptoAPI.
Edward Thomson committed -
Adding SHA256 support prompted an overdue refactoring of some of the unnecessary complexity around the CNG/CryptoAPI abstraction.
Edward Thomson committed -
The more generic GIT_ERROR_SHA allows for SHA256 errors as well as SHA1.
Edward Thomson committed -
Eliminate the `sha1` folder, move it down into `hash` so that future impelmentations can share common code.
Edward Thomson committed
-
- 23 Feb, 2022 2 commits
-
-
Instead of simply including the utility files directly, make them a cmake object library for easy reusability between other projects within libgit2. Now the top-level `src` is responsible for platform selection, while the next-level `libgit2` and `util` configurations are responsible for identifying what objects they include.
Edward Thomson committed -
Edward Thomson committed
-
- 02 Oct, 2021 1 commit
-
-
Separate the concerns of the hash functions from the git_oid functions. The git_oid structure will need to understand either SHA1 or SHA256; the hash functions should only deal with the appropriate one of these.
Edward Thomson committed
-
- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 11 Oct, 2020 1 commit
-
-
Provide a mechanism for system components to register for initialization and shutdown of the libgit2 runtime.
Edward Thomson committed
-
- 18 Jul, 2019 1 commit
-
-
In commit bbf034ab (hash: move `git_hash_prov` into Win32 backend, 2019-02-22), the `git_hash_prov`'s structure name has been removed in favour of its typedef'ed name. But as we have no CI that compiles with the WinHTTPS hashing backend right now, it wasn't noticed that the implementation that uses this struct wasn't changed correctly. Fix the struct type to make it compile again.
Patrick Steinhardt committed
-
- 24 Jun, 2019 4 commits
-
-
Create a separate `git_hash_sha1_ctx` structure that is specific to the SHA1 implementation and move all SHA1 functions over to use that one instead of the generic `git_hash_ctx`. The `git_hash_ctx` for now simply has a union containing this single SHA1 implementation, only, without any mechanism to distinguish between different algortihms.
Patrick Steinhardt committed -
As a preparatory step to allow multiple hashing APIs to exist at the same time, split the hashing functions into one layer for generic hashing and one layer for SHA1-specific hashing. Right now, this is simply an additional indirection layer that doesn't yet serve any purpose. In the future, the generic API will be extended to allow for choosing which hash to use, though, by simply passing an enum to the hash context initialization function. This is necessary as a first step to be ready for Git's move to SHA256.
Patrick Steinhardt committed -
As we will include additional hash algorithms in the future due to upstream git discussing a move away from SHA1, we should accomodate for that and prepare for the move. As a first step, move all SHA1 implementations into a common subdirectory. Also, create a SHA1-specific header file that lives inside the hash folder. This header will contain the SHA1-specific header includes, function declarations and the SHA1 context structure.
Patrick Steinhardt committed -
The hash source files have circular include dependencies right now, which shows by our broken generic hash implementation. The "hash.h" header declares two functions and the `git_hash_ctx` typedef before actually including the hash backend header and can only declare the remaining hash functions after the include due to possibly static function declarations inside of the implementation includes. Let's break this cycle and help maintainability by creating a real implementation file for each of the hash implementations. Instead of relying on the exact include order, we now especially avoid the use of `GIT_INLINE` for function declarations.
Patrick Steinhardt committed
-
- 04 Apr, 2019 1 commit
-
-
Users of the Win32 hash cannot be inlined, as it uses a static struct. Don't inline it, but continue to declare the function in the header.
Edward Thomson committed
-
- 23 Mar, 2019 1 commit
-
-
This means the forward declaration isn't necessary. The forward declaration can cause compilation errors as it conflicts with the `GIT_INLINE` declaration (the signatures are different).
Aaron Patterson committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 09 Feb, 2018 2 commits
-
-
Patrick Steinhardt committed
-
Edward Thomson committed
-
- 20 Dec, 2017 1 commit
-
-
Teach the win32 hash mechanisms to support large files. The hash primitives take at most `ULONG_MAX` bytes at a time. Loop, giving the hash function the maximum supported number of bytes, until we have hashed the entire file.
Edward Thomson committed
-
- 03 Jul, 2017 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 08 Nov, 2014 1 commit
-
-
This describes their purpose better, as we now initialize ssl and some other global stuff in there. Calling the init function is not something which has been optional for a while now.
Carlos Martín Nieto committed
-
- 17 Sep, 2013 1 commit
-
-
Increasingly there are a number of components that want to do some cleanup at global shutdown time (at least if there are not going to be memory leaks). This creates a very simple system of shutdown hooks that will be invoked by git_threads_shutdown. Right now, the maximum number of hooks is hardcoded, but since adding a hook is not a public API, it should be fine and I thought it was better to start off with really simple code.
Russell Belfer committed
-
- 28 Aug, 2013 1 commit
-
-
Edward Thomson committed
-
- 26 Aug, 2013 1 commit
-
-
This loads SRWLock APIs at runtime and in their absence (i.e. on Windows before Vista) falls back on a regular CRITICAL_SECTION that will not permit concurrent readers.
Russell Belfer committed
-
- 26 Feb, 2013 1 commit
-
-
This reverts commit efe7fad6, except for the indentation fixes.
Michael Schubert committed
-
- 25 Feb, 2013 1 commit
-
-
Along with that, fix indentation in tests-clar/object/raw/hash.c
Michael Schubert committed
-
- 08 Jan, 2013 1 commit
-
-
Edward Thomson committed
-
- 27 Nov, 2012 1 commit
-
-
Russell Belfer committed
-
- 13 Nov, 2012 4 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-
Edward Thomson committed
-