- 27 Jun, 2019 1 commit
-
-
When no hash algorithm has been initialized in a given hash context, then we will simply `assert` and not return a value at all. This works just fine in debug builds, but on non-debug builds the assert will be converted to a no-op and thus we do not have a proper return value. Fix this by returning an error code in addition to the asserts.
Patrick Steinhardt committed
-
- 24 Jun, 2019 3 commits
-
-
Create an enum that allows us to distinguish between different hashing algorithms. This enum is embedded into each `git_hash_ctx` and will instruct the code to which hashing function the particular request shall be dispatched. As we do not yet have multiple hashing algorithms, we simply initialize the hash algorithm to always be SHA1. At a later point, we will have to extend the `git_hash_init_ctx` function to get as parameter which algorithm shall be used.
Patrick Steinhardt committed -
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
-
- 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 Jan, 2013 1 commit
-
-
Edward Thomson committed
-
- 13 Nov, 2012 2 commits
-
-
Edward Thomson committed
-
Edward Thomson committed
-
- 13 Feb, 2012 1 commit
-
-
Signed-off-by: schu <schu-github@schulog.org>
schu committed
-
- 29 Oct, 2011 1 commit
-
-
Ensure that all memory related functions (malloc, calloc, strdup, free, etc) are using their respective `git__` wrappers.
Vicent Marti committed
-
- 18 Sep, 2011 1 commit
-
-
1. The license header is technically not valid if it doesn't have a copyright signature. 2. The COPYING file has been updated with the different licenses used in the project. 3. The full GPLv2 header in each file annoys me.
Vicent Marti committed
-
- 01 Jul, 2011 1 commit
-
-
This will make libgit2 more suitable for embedding.
Vicent Marti committed
-
- 07 Jun, 2010 1 commit
-
-
Given that the sha1.h header file should never be included into any other file, since it represents an implementation detail of hash.c, we remove the header and inline it's content. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Ramsay Jones committed
-
- 04 May, 2010 1 commit
-
-
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Ramsay Jones committed
-
- 14 Apr, 2010 1 commit
-
-
Since block-sha1 from git.git has such excellent performance, we can also get rid of the openssl dependency. It's rather simple to add it back later as an optional extra, but we really needn't bother to pull in the entire ssl library and have to deal with linking issues now that we have the portable and, performance-wise, truly excellent block-sha1 code to fall back on. Since this requires a slight revamp of the build rules anyway, we take the opportunity to fix including EXTRA_OBJS in the final build as well. The block-sha1 code was originally implemented for git.git by Linus Torvalds <torvalds@linux-foundation.org> and was later polished by Nicolas Pitre <nico@cam.org>. Signed-off-by: Andreas Ericsson <ae@op5.se>
Andreas Ericsson committed
-
- 18 Mar, 2009 1 commit
-
-
Paul agreed to the GCC-exception license by email: | | From: Paul Kocher <paul@cryptography.com> | Date: Sun, 15 Mar 2009 11:37:23 -0700 | Subject: Re: Adding Mozilla SHA1 implementation to libgit2 | | Yes - that's fine. | | At 01:56 AM 3/5/2009, Andreas Ericsson wrote: | > Hi Paul. We spoke earlier about this, if you remember? | > We'd like to add the GCC-exception to the GPL license | > for these files. Signed-off-by: Paul Kocher <paul@cryptography.com> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ramsay Jones committed
-
- 31 Dec, 2008 1 commit
-
-
We now forbid direct use of malloc, strdup or calloc within the library and instead use wrapper functions git__malloc, etc. to invoke the underlying library malloc and set git_errno to a no memory error code if the allocation fails. In the future once we have pack objects in memory we are likely to enhance these routines with garbage collection logic to purge cached pack data when allocations fail. Because the size of the function will grow somewhat large, we don't want to mark them for inline as gcc tends to aggressively inline, creating larger than expected executables. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed
-
- 30 Dec, 2008 1 commit
-
-
[sp: Changed signature for output to use git_oid, and added a test case to verify an allocated git_hash_ctx can be reinitialized and reused.] Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ramsay Jones committed
-
- 22 Nov, 2008 1 commit
-
-
Otherwise their prototypes don't match their declarations. Detected by 'sparse', which is obviously good to run before each commit. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andreas Ericsson committed
-
- 18 Nov, 2008 1 commit
-
-
git_revp is something I personally can't stop pronouncing "rev pointer". I'm sure others would suffer the same problem. Also, rename the git_revp_ sub-api "gitrp_". This is the first of many such renames, primarily done to prevent extreme inflation in the "git_" namespace, which we'd like to reserve for a higher-level API. While we're at it, we remove the noise-char "c" from a lot of functions. Since revision walking is all about commits, the common case should be that we're dealing with commits. Exceptions can get a more mnemonic description as needed. Signed-off-by: Andreas Ericsson <ae@op5.se> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andreas Ericsson committed
-
- 01 Nov, 2008 5 commits
-
-
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
This isn't the best idea I've head. Pierre Habouzit was suggesting a technique of assigning a unique integer to each commit and then allocating storage out of auxiliary pools, using the commit's unique integer to index into any auxiliary pool in constant time. This way both applications and the library can efficiently attach arbitrary data onto a commit, such as rewritten parents, or flags, and have them disconnected from the main object hash table. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
This seems to be preferred on the mailing list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed
-
- 31 Oct, 2008 6 commits
-
-
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
This way only structures we ask the caller to allocate on their call stack or which we want to allow them to use members from are shown in the API docs. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Most read calls will use the small object format, as the majority of the content within the database is very small objects (under 20 KB when inflated). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed -
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce committed
-