summaryrefslogtreecommitdiff
path: root/src/midx.c
Commit message (Collapse)AuthorAgeFilesLines
* path: separate git-specific path functions from utilEdward Thomson2021-11-091-4/+4
| | | | | | 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).
* str: introduce `git_str` for internal, `git_buf` is externalethomson/gitstrEdward Thomson2021-10-171-51/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* hash: hash functions operate on byte arrays not git_oidsEdward Thomson2021-10-021-2/+2
| | | | | | 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.
* hash: accept the algorithm in inputsEdward Thomson2021-10-011-2/+2
|
* midx: return an error when detectedEdward Thomson2021-08-301-3/+7
|
* Review feedbacklhchavez2021-08-271-15/+17
|
* midx: Add a way to write multi-pack-index fileslhchavez2021-07-261-0/+396
| | | | | | | 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
* Merge pull request #5768 from lhchavez/midx-needs-refreshEdward Thomson2021-01-151-1/+1
|\ | | | | midx: Fix a bug in `git_midx_needs_refresh()`
| * midx: Fix a bug in `git_midx_needs_refresh()`lhchavez2021-01-071-1/+1
| | | | | | | | | | The very last check in the freshness check for the midx was wrong >< This was also because this function was not tested.
* | Use `p_pwrite`/`p_pread` consistently throughout the codebaselhchavez2021-01-071-6/+1
|/ | | | | | 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).
* midx: Support multi-pack-index files in odb_pack.clhchavez2020-11-271-6/+67
| | | | | | | | | | | | 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
* midx: use GIT_ASSERTEdward Thomson2020-11-271-4/+7
|
* multipack: Introduce a parser for multi-pack-index fileslhchavez2020-10-051-0/+418
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
View Lorry Controller Status