- 12 Feb, 2023 1 commit
-
-
Teach the packfile machinery to cope with SHA256.
Edward Thomson committed
-
- 09 Jul, 2022 1 commit
-
-
Pack files v3 are introduced in the SHA256 hash transition document https://github.com/git/git/blob/master/Documentation/technical/hash-function-transition.txt Obviously we do not support these yet. Stop pretending that we do.
Edward Thomson committed
-
- 10 Apr, 2022 1 commit
-
-
A packfile contains arrays of raw oid data, use a byte array to index into them.
Edward Thomson committed
-
- 23 Feb, 2022 1 commit
-
-
Edward Thomson committed
-
- 27 Aug, 2021 2 commits
- 27 Jul, 2021 1 commit
-
-
This change adds the git_midx_writer_* functions to allow to write and create `multi-pack-index` files from `.idx`/`.pack` files. Part of: #5399
lhchavez committed
-
- 06 Dec, 2020 1 commit
-
-
Clarify the `git_atomic` type and functions now that we have a 64 bit version as well (`git_atomic64`).
Edward Thomson committed
-
- 29 Nov, 2020 1 commit
-
-
This change fixes a packfile heap corruption that can happen when interacting with multiple packfiles concurrently across multiple threads. This is exacerbated by setting a lower mwindow open file limit. This change: * Renames most of the internal methods in pack.c to clearly indicate that they expect to be called with a certain lock held, making reasoning about the state of locks a bit easier. * Splits the `git_pack_file` lock in two: the one in `git_pack_file` only protects the `index_map`. The protection to `git_mwindow_file` is now in that struct. * Explicitly checks for freshness of the `git_pack_file` in `git_packfile_unpack_header`: this allows the mwindow implementation to close files whenever there is enough cache pressure, and `git_packfile_unpack_header` will reopen the packfile if needed. * After a call to `p_munmap()`, the `data` and `len` fields are poisoned with `NULL` to make use-after-frees more evident and crash rather than being open to the possibility of heap corruption. * Adds a test case to prevent this from regressing in the future. Fixes: #5591
lhchavez committed
-
- 27 Nov, 2020 1 commit
-
-
Edward Thomson committed
-
- 05 Oct, 2020 1 commit
-
-
This change is the first in a series to add support for git's multi-pack-index. This should speed up large repositories significantly. Part of: #5399
lhchavez committed
-
- 01 Apr, 2020 1 commit
-
-
This makes get_delta_base() return the error code as the return value and the delta base as an out-parameter.
lhchavez committed
-
- 09 Jan, 2020 1 commit
-
-
While we do have a `git_zstream` abstraction that encapsulates all the calls to zlib as well as its error handling, we do not use it in our pack file code. Refactor it to make the code a lot easier to understand.
Patrick Steinhardt committed
-
- 25 Nov, 2019 1 commit
-
-
Prefer `off64_t` internally.
Edward Thomson committed
-
- 15 Feb, 2019 1 commit
-
-
Currently, the lifecycle functions for maps (allocation, deallocation, resize) are not named in a uniform way and do not have a uniform function signature. Rename the functions to fix that, and stick to libgit2's naming scheme of saying `git_foo_new`. This results in the following new interface for allocation: - `int git_<t>map_new(git_<t>map **out)` to allocate a new map, returning an error code if we ran out of memory - `void git_<t>map_free(git_<t>map *map)` to free a map - `void git_<t>map_clear(git<t>map *map)` to remove all entries from a map This commit also fixes all existing callers.
Patrick Steinhardt committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
The function `git_packfile_stream_free` frees all state of the packfile stream without freeing the structure itself. This naming makes it hard to spot whether it will try to free the pointer itself or not, causing potential future errors. Due to this reason, we have decided to name a function freeing state without freeing the actual struture a "dispose" function. Rename `git_packfile_stream_free` to `git_packfile_stream_dispose` as a first example following this rule.
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
-
- 21 Jan, 2017 1 commit
-
-
Encapsulation!
Edward Thomson committed
-
- 04 Aug, 2016 1 commit
-
-
Since writing multiple objects may all already exist in a single packfile, avoid freshening that packfile repeatedly in a tight loop. Instead, only freshen pack files every 2 seconds.
Edward Thomson committed
-
- 13 Jan, 2016 1 commit
-
-
P.S.V.R committed
-
- 11 Mar, 2015 1 commit
-
-
Keep the definitions in the headers, while putting the declarations in the C files. Putting the function definitions in headers causes them to be duplicated if you include two headers with them.
Carlos Martín Nieto committed
-
- 15 Feb, 2015 1 commit
-
-
Without this change, compiling with gcc and pedantic generates warning: ISO C does not allow extra ‘;’ outside of a function.
Stefan Widgren committed
-
- 23 Jun, 2014 1 commit
-
-
Opening the same repository multiple times will currently open the same file multiple times, as well as map the same region of the file multiple times. This is not necessary, as the packfile data is immutable. Instead of opening and closing packfiles directly, introduce an indirection and allocate packfiles globally. This does mean locking on each packfile open, but we already use this lock for the global mwindow list so it doesn't introduce a new contention point.
Carlos Martín Nieto committed
-
- 13 May, 2014 1 commit
-
-
Instead of going through a special entry in the chain, let's pass it as an output parameter.
Carlos Martín Nieto committed
-
- 09 May, 2014 2 commits
-
-
Bring back the use of the delta base cache for unpacking objects. When generating the delta chain, we stop when we find a delta base in the pack's cache and use that as the starting point.
Carlos Martín Nieto committed -
We currently make use of recursive function calls to unpack an object, resolving the deltas as we come back down the chain. This means that we have unbounded stack growth as we look up objects in a pack. This is now done in two steps: first we figure out what the dependency chain is by looking up the delta bases until we reach a non-delta object, pushing the information we need onto a stack and then we pop from that stack and apply the deltas until there are no more left. This version of the code does not make use of the delta base cache so it is slower than what's in the mainline. A later commit will reintroduce it.
Carlos Martín Nieto committed
-
- 23 Jan, 2014 1 commit
-
-
Linquize committed
-
- 01 Nov, 2013 2 commits
-
-
Vicent Marti committed
-
Linquize committed
-
- 04 Oct, 2013 1 commit
-
-
Carlos Martín Nieto committed
-
- 22 Apr, 2013 3 commits
-
-
Rename git_packfile_check to git_packfile_alloc since it is now being used more in that capacity. Fix the various places that use it. Consolidate some repeated code in odb_pack.c related to the allocation of a new pack_backend.
Russell Belfer committed -
This builds on the earlier thread safety work to make it so that setting the odb, index, refdb, or config for a repository is done in a threadsafe manner with minimized locking time. This is done by adding a lock to the repository object and using it to guard the assignment of the above listed pointers. The lock is only held to assign the pointer value. This also contains some minor fixes to the other work with pack files to reduce the time that locks are being held to and fix an apparently memory leak.
Russell Belfer committed -
When I was writing threading tests for the new cache, the main error I kept running into was a pack file having it's content unmapped underneath the running thread. This adds a lock around the routines that map and unmap the pack data so that threads can effectively reload the data when they need it. This also required reworking the error handling paths in a couple places in the code which I tried to make consistent.
Russell Belfer committed
-
- 03 Mar, 2013 1 commit
-
-
These offsets are needed for REF_DELTA objects, which encode which object they use as a base, but not where it lies in the packfile, so we need a list. These objects are mostly from older packfiles, before OFS_DELTA was widely spread. The time spent in indexing these packfiles is greatly reduced, though remains above what git is able to do.
Carlos Martín Nieto committed
-
- 12 Jan, 2013 1 commit
-
-
The indexer needs to call the packfile's free function so it takes care of freeing the caches. We still need to close the mwf descriptor manually so we can rename the packfile into its final name on Windows.
Carlos Martín Nieto committed
-
- 11 Jan, 2013 4 commits
-
-
This reverts commit f289f886, which makes the tests fail on Windows. Revert until we can figure out a solution.
Carlos Martín Nieto committed -
Vicent Marti committed
-
Currently limited to 16MB (like git) and to objects up to 1MB in size.
Carlos Martín Nieto committed -
Carlos Martín Nieto committed
-