- 09 Nov, 2021 1 commit
-
-
Introduce `git_fs_path`, which operates on generic filesystem paths. `git_path` will be kept for only git-specific path functionality (for example, checking for `.git` in a path).
Edward Thomson committed
-
- 17 Oct, 2021 1 commit
-
-
libgit2 has two distinct requirements that were previously solved by `git_buf`. We require: 1. A general purpose string class that provides a number of utility APIs for manipulating data (eg, concatenating, truncating, etc). 2. A structure that we can use to return strings to callers that they can take ownership of. By using a single class (`git_buf`) for both of these purposes, we have confused the API to the point that refactorings are difficult and reasoning about correctness is also difficult. Move the utility class `git_buf` to be called `git_str`: this represents its general purpose, as an internal string buffer class. The name also is an homage to Junio Hamano ("gitstr"). The public API remains `git_buf`, and has a much smaller footprint. It is generally only used as an "out" param with strict requirements that follow the documentation. (Exceptions exist for some legacy APIs to avoid breaking callers unnecessarily.) Utility functions exist to convert a user-specified `git_buf` to a `git_str` so that we can call internal functions, then converting it back again.
Edward Thomson committed
-
- 30 Aug, 2021 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
-
- 07 Jan, 2021 1 commit
-
-
This change stops using the seek+read/write combo to perform I/O with an offset, since this is faster by one system call (and also more atomic and therefore safer).
lhchavez committed
-
- 15 Dec, 2020 1 commit
-
-
Continue the zlib stream as long as we can make progress; stop when we stop getting output _or_ when zlib stops taking input from us.
Edward Thomson 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
-
- 28 Nov, 2020 1 commit
-
-
This change adds all the necessary locking to the odb to avoid races in the backends. Part of: #5592
lhchavez committed
-
- 27 Nov, 2020 2 commits
-
-
This change adds support for reading multi-pack-index files from the packfile odb backend. This also makes git_pack_file objects open their backing failes lazily in more scenarios, since the multi-pack-index can avoid having to open them in some cases (yay!). This change also refreshes the documentation found in src/odb_pack.c to match the updated code. Part of: #5399
lhchavez committed -
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
-
- 05 Aug, 2020 2 commits
-
-
Edward Thomson committed
-
Our processing loop in git_zstream_get_output_chunk does not handle `Z_BUF_ERROR` appropriately at the end of a compressed window. From the zlib manual, inflate will return: > Z_BUF_ERROR if no progress was possible or if there was not enough > room in the output buffer when Z_FINISH is used. Note that Z_BUF_ERROR > is not fatal, and inflate() can be called again with more input and > more output space to continue decompressing. In our loop, we were waiting until we got the expected size, then ensuring that we were at `Z_STREAM_END`. We are not guaranteed to be, since zlib may be in the `Z_BUF_ERROR` state where it has consumed a full window's worth of data, but it doesn't know that it's really at the end of the stream. There _could_ be more compressed data, but it doesn't _know_ that there's not until we make a subsequent call. We can change the loop to look for the end of stream instead of our expected size. This allows us to call inflate one last time when we are at the end of a window (and in the `Z_BUF_ERROR` state), allowing it to recognize the end of the stream, and move from the `Z_BUF_ERROR` state to the `Z_STREAM_END` state. If we do this, we need another exit condition: when `bytes == 0`, then no progress could be made and we should stop trying to inflate. This will be an error case, caught by the size and/or end-of-stream test.
Edward Thomson committed
-
- 02 Apr, 2020 1 commit
-
-
lhchavez committed
-
- 01 Apr, 2020 2 commits
-
-
This makes get_delta_base() return the error code as the return value and the delta base as an out-parameter.
lhchavez committed -
This change moves the responsibility of setting the error upon failures of get_delta_base() to get_delta_base() instead of its callers. That way, the caller chan always check if the return value is negative and mark the whole operation as an error instead of using garbage values, which can lead to crashes if the .pack files are malformed.
lhchavez committed
-
- 07 Feb, 2020 1 commit
-
-
The file "sha1_lookup.c" contains a single function `sha1_position` only which is used only in the packfile implementation. As the function is comparatively small, to enable the compiler to optimize better and to remove symbol visibility, move it into "pack.c".
Patrick Steinhardt committed
-
- 09 Jan, 2020 2 commits
-
-
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 -
While we do have a 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
-
- 20 Jul, 2019 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 15 Feb, 2019 4 commits
-
-
Currently, there is only one caller that adds entries into an offset map, and this caller first uses `git_offmap_put` to add a key and then set the value at the returned index by using `git_offmap_set_value_at`. This is just too tighlty coupled with implementation details of the map as it exposes the index of inserted entries, which we really do not care about at all. Introduce a new function `git_offmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert the caller to make use of it instead.
Patrick Steinhardt committed -
The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_offmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
Patrick Steinhardt committed -
The current way of looking up an entry from a map is tightly coupled with the map implementation, as one first has to look up the index of the key and then retrieve the associated value by using the index. As a caller, you usually do not care about any indices at all, though, so this is more complicated than really necessary. Furthermore, it invites for errors to happen if the correct error checking sequence is not being followed. Introduce a new high-level function `git_oidmap_get` that takes a map and a key and returns a pointer to the associated value if such a key exists. Otherwise, a `NULL` pointer is returned. Adjust all callers that can trivially be converted.
Patrick Steinhardt committed -
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
-
- 02 Feb, 2019 1 commit
-
-
Dhruva Krishnamurthy committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 17 Jan, 2019 1 commit
-
-
We use the term "invalid" to refer to bad or malformed data, eg `GIT_REF_INVALID` and `GIT_EINVALIDSPEC`. Since we're changing the names of the `git_object_t`s in this release, update it to be `GIT_OBJECT_INVALID` instead of `BAD`.
Edward Thomson committed
-
- 01 Dec, 2018 1 commit
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed
-
- 28 Nov, 2018 1 commit
-
-
Instead of using the `khiter_t`, `git_strmap_iter` and `khint_t` types, simply use `size_t` instead. This decouples code from the khash stuff and makes it possible to move the khash includes into the implementation files.
Patrick Steinhardt committed
-
- 10 Jun, 2018 2 commits
-
-
Patrick Steinhardt committed
-
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
-
- 23 Dec, 2017 1 commit
-
-
If an element has been cached, but then the call to packfile_unpack_compressed() fails, the very next thing that happens is that its data is freed and then the element is not removed from the cache, which frees the data again. This change sets obj->data to NULL to avoid the double-free. It also stops trying to resolve deltas after two continuous failed rounds of resolution, and adds a test for this.
lhchavez committed
-
- 15 Dec, 2017 1 commit
-
-
lhchavez committed
-
- 09 Dec, 2017 1 commit
-
-
lhchavez committed
-
- 08 Dec, 2017 1 commit
-
-
The type of |base_offset| in get_delta_base() is `git_off_t`, which is a signed `long`. That means that we need to make sure that the 8 most significant bits are zero (instead of 7) to avoid an overflow when it is shifted by 7 bits. Found using libFuzzer.
lhchavez committed
-
- 09 Aug, 2017 1 commit
-
-
This was pulled over from git.git, and is an experiment in making binary-searching lists of sha1s faster. It was never compiled by default (nor was it used upstream by default without a special environment variable). Unfortunately, it is actually slower in practice, and upstream is planning to drop it in git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has some timing results). It's worth doing the same here for simplicity.
Jeff King committed
-