- 22 Feb, 2019 2 commits
-
-
refdb_fs: fix loose/packed refs lookup racing with repacks
Edward Thomson committed -
Allocator restructuring
Edward Thomson committed
-
- 21 Feb, 2019 12 commits
-
-
cache: fix misnaming of `git_cache_free`
Patrick Steinhardt committed -
examples: produce single cgit2 binary
Patrick Steinhardt committed -
Functions that free a structure's contents but not the structure itself shall be named `dispose` in the libgit2 project, but the function `git_cache_free` does not follow this naming pattern. Fix this by renaming it to `git_cache_dispose` and adjusting all callers to make use of the new name.
Patrick Steinhardt committed -
In commit 6e0dfc6f (Make stdalloc__reallocarray call stdalloc__realloc, 2019-02-16), we have changed the stdalloc allocator to reuse `stdalloc__realloc` to implement `stdalloc__reallocarray`. This commit is making the same change for the Windows-specific crtdbg allocator to avoid code duplication.
Patrick Steinhardt committed -
The Windows-specific crtdbg allocator is currently mixed into the crtdbg stacktracing compilation unit, making it harder to find than necessary. Extract it and move it into the new "allocators/" subdirectory to improve discoverability. This change means that the crtdbg compilation unit is now compiled unconditionally, whereas it has previously only been compiled on Windows platforms. Thus we now have additional guards around the code so that it will only be compiled if GIT_MSVC_CRTDBG is defined. This also allows us to move over the fallback-implementation of `git_win32_crtdbg_init_allocator` into the same compilation unit.
Patrick Steinhardt committed -
Right now, our two allocator implementations are scattered around the tree in "stdalloc.h" and "win32/w32_crtdbg_stacktrace.h". Start grouping them together in a single directory "allocators/", similar to how e.g. our streams are organized.
Patrick Steinhardt committed -
Remove public 'inttypes.h' header
Patrick Steinhardt committed -
Remove an `inttypes.h` header that is too large in scope, and far too public. For Visual Studio 2012 and earlier (ie, `_MSC_VER < 1800`), we do need to include `stdint.h` in our public headers, for types like `uint32_t`. Internally, we also need to define `PRId64` as a printf formatting string when it is not available.
Edward Thomson committed -
Prevent reading out of bounds memory
Patrick Steinhardt committed -
Previously, we would fail to correctly truncate the source buffer if the source has more than one line and ends with a non-newline character. In the following call, we thus truncate the source string in the middle of the second line. Without the bug fixed, we would successfully apply the patch to the source and return success. With the overflow being fixed, we should return an error now.
Patrick Steinhardt committed -
When parsing the patch image from a string, we split the string by newlines to get a line-based view of it. To split, we use `memchr` on the buffer and limit the buffer length by the original length provided by the caller. This works just fine for the first line, but for every subsequent line we need to actually subtract the amount of bytes that we have already read. The above issue can be easily triggered by having a source buffer with at least two lines, where the second line does _not_ end in a newline. Given a string "foo\nb", we have an original length of five bytes. After having extracted the first line, we will point to 'b' and again try to `memchr(p, '\n', 5)`, resulting in an out-of-bounds read of four bytes. Fix the issue by correctly subtracting the amount of bytes already read.
Erik Aigner committed -
Fix a memory leak in odb_otype_fast()
Patrick Steinhardt committed
-
- 20 Feb, 2019 4 commits
-
-
This change frees a copy of a cached object in odb_otype_fast().
lhchavez committed -
Make stdalloc__reallocarray call stdalloc__realloc
Patrick Steinhardt committed -
Remove `git_time_monotonic`
Patrick Steinhardt committed -
Fix a _very_ improbable memory leak in git_odb_new()
Patrick Steinhardt committed
-
- 17 Feb, 2019 8 commits
-
-
`git_time_monotonic` was added so that non-native bindings like rugged could get high-resolution timing for benchmarking. However, this is outside the scope of libgit2 *and* rugged decided not to use this function in the first place. Google suggests that absolutely _nobody_ is using this function and we don't want to be in the benchmarking business. Remove the function.
Edward Thomson committed -
ci: publish documentation on merge
Edward Thomson committed -
When a commit is pushed or merged into one of the release branches (master, maint/*) then push the documentation update to gh-pages.
Edward Thomson committed -
This reverts commit 2a4e866a.
Edward Thomson committed -
Edward Thomson committed
-
Edward Thomson committed
-
When a continuous integration build runs (ie a commit is pushed or merged into one of the CI branches, `master` or `maint/*`) then push the rebuilt documentation into the `gh-pages` branch.
Edward Thomson committed -
This change fixes a mostly theoretical memory leak in got_odb_new() that can only manifest if git_cache_init() fails due to running out of memory or not being able to acquire its lock.
lhchavez committed
-
- 16 Feb, 2019 1 commit
-
-
This change avoids calling realloc(3) in more than one place.
lhchavez committed
-
- 15 Feb, 2019 11 commits
-
-
Etienne Samson committed
-
Patrick Steinhardt committed
-
Inside of our networking example code, we have a git2 executable that acts as an entry point to all the different network examples. As such, it is kind of the same like the normal git(1) executable in that it simply arbitrates to the respective subcommands. Let's extend this approach and merge all examples into a single standalone lg2 executable. Instead of building an executable for all the existing examples we have, we now bundle them all inside of the lg2 one and let them be callable via subcommands. In the process, we can get rid of duplicated library initialization, deinitialization and repository discovery code. Instead of having each subcommand handle these on its own, we simply do it inside of the single main function now.
Patrick Steinhardt committed -
Right now, we have two sets of "common" code, one containing general common code and one containing network common code. As we intend to get rid of the network subdirectory and instead merge all examples into a single standalone executable, this distinction doesn't make a lot of sense now. Furthermore, the common network code is not that big. Let's get rid of the common network code by merging it into the general common code.
Patrick Steinhardt committed -
This Makefile isn't used anymore and probably won't work anyway. Remove it in favor of the existing CMake build instructions.
Patrick Steinhardt committed -
In commit 2e233285 (examples: a test, for rev-list, 2013-03-20), a script was introduced with the intention of testing our rev-list example code. Nobody uses that script, and in fact it doesn't even properly work due to the not-so-recent addition out-of-source builds. Remove the script.
Patrick Steinhardt committed -
Right now, we first load the packed refs cache and only afterwards load the loose references. This is susceptible to a race when the loose ref is being migrated to a packed cache by e.g. git-pack-refs(1): libgit2 git-pack-refs 1. We load the packed ref, which does not yet have the migrated reference. 2. git-pack-refs updates the packed ref file to have the migrated ref. 3. git-pack-refs deletes the old loose ref. 4. We look up the loose ref. So we now do not find the reference at all and will never iterate over it. Fix the issue by reversing the order: instead of first loading the packed refs, we will now look up the loose reference first. If it has already been deleted, then it must already be present in the packed-refs by definition, as git.git will only delete the reference after updating the packed refs file.
Patrick Steinhardt committed -
Right now, loading loose refs has the side-effect of setting the `PACKREF_SHADOWED` flag for references that exist both in the loose and the packed refs. Because of this, we are force do first look up packed refs and only afterwards loading the packed refs. This is susceptible to a race, though, when refs are being repacked: when first loading the packed cache, then it may not yet have the migrated loose ref. But when now trying to look up the loose reference afterwards, then it may already have been migrated. Thus, we would fail to find this reference in this scenario. Remove this ordering dependency to allow fixing the above race. Instead of setting the flag when loading loose refs, we will now instead set it lazily when iterating over the loose refs. This even has the added benefit of not requiring us to lock the packed refs cache, as we already have an owned copy of it.
Patrick Steinhardt committed -
When creating a new iterator, we eagerly load loose refs but only lazily create a copy of packed refs. The lazy load only happens as soon as we have iterated over all loose refs, opening up a potentially wide window for races. This may lead to an inconsistent view e.g. when the caller decides to reload packed references somewhen between iterating the loose refs, which is unexpected. Fix the issue by eagerly copying the sorted cache. Note that right now, we are heavily dependent on ordering here: we first need to reload packed refs, then we have to load loose refs and only as a last step are we allowed to copy the cache. This is because loading loose refs has the side-effect of setting the `PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid outputting packed refs that already exist as loose refs.
Patrick Steinhardt committed -
Refactor the error handling in `refdb_fs_backend__iterator` to always return the correct error code returned by the failing function.
Patrick Steinhardt committed -
When repacking references, git.git will first update the packed refs and only afterwards delete any existing loose references that have now been moved to the new packed refs file. Due to this, there is a potential for racing if one first reads the packfile (which has not been updated yet) and only then trying to read the loose reference (which has just been deleted). In this case, one will incorrectly fail to lookup the reference and it will be reported as missing. Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`. Fix the race by reversing the lookup: we will now first check if the loose reference exists and only afterwards refresh the packed file.
Patrick Steinhardt committed
-
- 14 Feb, 2019 2 commits
-
-
Enable creation of worktree from bare repo's default branch
Edward Thomson committed -
Allow bypassing check for '.keep' file
Edward Thomson committed
-