summaryrefslogtreecommitdiff
path: root/src/index.c
Commit message (Collapse)AuthorAgeFilesLines
* filebuf: use hashes not oidsEdward Thomson2021-11-221-1/+1
| | | | | The filebuf functions should use hashes directly, not indirectly using the oid functions.
* Make enum in src,tests and examples C90 compliant by removing trailing comma.Peter Pettersson2021-11-151-1/+1
|
* path: `validate` -> `is_valid`Edward Thomson2021-11-091-1/+1
| | | | | Since we're returning a boolean about validation, the name is more properly "is valid".
* path: separate git-specific path functions from utilEdward Thomson2021-11-091-4/+5
| | | | | | 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-34/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | 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-1/+1
|
* use git_repository_workdir_path to generate pathsEdward Thomson2021-04-281-2/+2
| | | | | Use `git_repository_workdir_path` to generate workdir paths since it will validate the length.
* path: git_path_isvalid -> git_path_validateEdward Thomson2021-04-141-1/+1
| | | | | | | If we want to validate more and different types of paths, the name `git_path_validate` makes that easier and more expressive. We can add, for example, `git_path_validate_foo` while the current name makes that less ergonomic.
* index: Initialize case_sorted to GIT_VECTOR_INITpanda2021-02-181-5/+4
| | | | This is for extra safety within write_entries
* index: Check git_vector_dup error in write_entriespanda2021-02-161-1/+3
| | | | If allocating case_sorted.contents fails, git_vector_sort will segfault.
* threads: give atomic functions the git_atomic prefixEdward Thomson2020-12-061-4/+4
|
* threads: rename git_atomic to git_atomic32Edward Thomson2020-12-061-5/+5
| | | | | Clarify the `git_atomic` type and functions now that we have a 64 bit version as well (`git_atomic64`).
* index: use GIT_ASSERTEdward Thomson2020-11-271-59/+95
|
* Make the tests run cleanly under UndefinedBehaviorSanitizerlhchavez2020-06-301-6/+8
| | | | | | | | | | | | | | | | | | | | | | | This change makes the tests run cleanly under `-fsanitize=undefined,nullability` and comprises of: * Avoids some arithmetic with NULL pointers (which UBSan does not like). * Avoids an overflow in a shift, due to an uint8_t being implicitly converted to a signed 32-bit signed integer after being shifted by a 32-bit signed integer. * Avoids a unaligned read in libgit2. * Ignores unaligned reads in the SHA1 library, since it only happens on Intel processors, where it is _still_ undefined behavior, but the semantics are moderately well-understood. Of notable omission is `-fsanitize=integer`, since there are lots of warnings in zlib and the SHA1 library which probably don't make sense to fix and I could not figure out how to silence easily. libgit2 itself also has ~100s of warnings which are mostly innocuous (e.g. use of enum constants that only fit on an `uint32_t`, but there is no way to do that in a simple fashion because the data type chosen for enumerated types is implementation-defined), and investigating whether there are worrying warnings would need reducing the noise significantly.
* tree-wide: do not compile deprecated functions with hard deprecationPatrick Steinhardt2020-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | When compiling libgit2 with -DDEPRECATE_HARD, we add a preprocessor definition `GIT_DEPRECATE_HARD` which causes the "git2/deprecated.h" header to be empty. As a result, no function declarations are made available to callers, but the implementations are still available to link against. This has the problem that function declarations also aren't visible to the implementations, meaning that the symbol's visibility will not be set up correctly. As a result, the resulting library may not expose those deprecated symbols at all on some platforms and thus cause linking errors. Fix the issue by conditionally compiling deprecated functions, only. While it becomes impossible to link against such a library in case one uses deprecated functions, distributors of libgit2 aren't expected to pass -DDEPRECATE_HARD anyway. Instead, users of libgit2 should manually define GIT_DEPRECATE_HARD to hide deprecated functions. Using "real" hard deprecation still makes sense in the context of CI to test we don't use deprecated symbols ourselves and in case a dependant uses libgit2 in a vendored way and knows it won't ever use any of the deprecated symbols anyway.
* Merge pull request #5526 from libgit2/ethomson/poolinitPatrick Steinhardt2020-06-011-1/+2
|\ | | | | git_pool_init: allow the function to fail
| * git_pool_init: handle failure casesethomson/poolinitEdward Thomson2020-06-011-1/+2
| | | | | | | | Propagate failures caused by pool initialization errors.
* | index: write v4: bugfix: prefix path with strip_len, not same_lenPatrick Wang2020-05-261-2/+2
|/ | | | | According to index-format.txt of git, the path of an entry is prefixed with N, where N indicates the length of bytes to be stripped.
* index functions: return an intEdward Thomson2020-01-241-6/+17
| | | | | Stop returning a void for functions, future-proofing them to allow them to fail.
* index: fix resizing index map twice on case-insensitive systemsPatrick Steinhardt2020-01-141-17/+14
| | | | | | | | | | | | | | | | | | | | | | | Depending on whether the index map is case-sensitive or insensitive, we need to call either `git_idxmap_icase_resize` or `git_idxmap_resize`. There are multiple locations where we thus use the following pattern: if (index->ignore_case && git_idxmap_icase_resize(map, length) < 0) return -1; else if (git_idxmap_resize(map, length) < 0) return -1; The funny thing is: on case-insensitive systems, we will try to resize the map twice in case where `git_idxmap_icase_resize()` doesn't error. While this will still use the correct hashing function as both map types use the same, this bug will at least cause us to resize the map twice in a row. Fix the issue by introducing a new function `index_map_resize` that handles case-sensitivity, similar to how `index_map_set` and `index_map_delete`. Convert all call sites where we were previously resizing the map to use that new function.
* index: replace map macros with inline functionsPatrick Steinhardt2020-01-141-43/+34
| | | | | | | | | | | Traditionally, our maps were mostly implemented via macros that had weird call semantics. This shows in our index code, where we have macros that insert into an index map case-sensitively or insensitively, as they still return error codes via an error parameter. This is unwieldy and, most importantly, not necessary anymore, due to the introduction of our high-level map API and removal of macros. Replace them with inlined functions to make code easier to read.
* configuration: cvar -> configmapPatrick Steinhardt2019-07-181-3/+3
| | | | | `cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
* index: safely cast file sizeEdward Thomson2019-06-241-1/+6
|
* index: rename `frombuffer` to `from_buffer`Edward Thomson2019-06-161-1/+10
| | | | | | The majority of functions are named `from_something` (with an underscore) instead of `fromsomething`. Update the index functions for consistency with the rest of the library.
* blob: add underscore to `from` functionsEdward Thomson2019-06-161-1/+1
| | | | | | The majority of functions are named `from_something` (with an underscore) instead of `fromsomething`. Update the blob functions for consistency with the rest of the library.
* idxmap: have `resize` functions return proper error codePatrick Steinhardt2019-02-151-14/+22
| | | | | | | | | | The currently existing function `git_idxmap_resize` and `git_idxmap_icase_resize` do not return any error codes at all due to their previous implementation making use of a macro. Due to that, it is impossible to see whether the resize operation might have failed due to an out-of-memory situation. Fix this by providing a proper error code. Adjust callers to make use of it.
* idxmap: introduce high-level setter for key/value pairsPatrick Steinhardt2019-02-151-7/+7
| | | | | | | | | | | | Currently, one would use the function `git_idxmap_insert` to insert key/value pairs into a map. This function has historically been a macro, which is why its syntax is kind of weird: instead of returning an error code directly, it instead has to be passed a pointer to where the return value shall be stored. This does not match libgit2's common idiom of directly returning error codes. Introduce a new function `git_idxmap_set`, which takes as parameters the map, key and value and directly returns an error code. Convert all callers of `git_idxmap_insert` to make use of it.
* idxmap: introduce high-level getter for valuesPatrick Steinhardt2019-02-151-9/+10
| | | | | | | | | | | | | | 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 new high-level functions `git_idxmap_get` and `git_idxmap_icase_get` that take a map and a key and return 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.
* maps: use uniform lifecycle management functionsPatrick Steinhardt2019-02-151-7/+7
| | | | | | | | | | | | | | | | 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.
* index: explicitly cast down to a size_tEdward Thomson2019-01-251-1/+1
| | | | | | Quiet down a warning from MSVC about how we're potentially losing data. This cast is safe since we've explicitly tested that `strip_len` <= `last_len`.
* index: preserve extension parsing errorsEtienne Samson2019-01-241-14/+15
| | | | | | | Previously, we would clobber any extension-specific error message with an "extension is truncated" message. This makes `read_extension` correctly preserve those errors, takes responsibility for truncation errors, and adds a new message with the actual extension signature for unsupported mandatory extensions.
* git_error: use new names in internal APIs and usageEdward Thomson2019-01-221-48/+48
| | | | | Move to the `git_error` name in the internal API for error-related functions.
* index: use new enum and structure namesEdward Thomson2018-12-011-47/+47
| | | | Use the new-style index names throughout our own codebase.
* khash: remove intricate knowledge of khash typesPatrick Steinhardt2018-11-281-8/+8
| | | | | | | 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.
* Merge pull request #4884 from libgit2/ethomson/index_iteratorPatrick Steinhardt2018-11-211-0/+45
|\ | | | | index: introduce git_index_iterator
| * index: introduce git_index_iteratorethomson/index_iteratorEdward Thomson2018-11-141-0/+45
| | | | | | | | | | | | Provide a public git_index_iterator API that is backed by an index snapshot. This allows consumers to provide a stable iteration even while manipulating the index during iteration.
* | Merge pull request #4818 from pks-t/pks/index-collisionPatrick Steinhardt2018-11-131-45/+40
|\ \ | |/ |/| Index collision fixes
| * index: fix adding index entries with conflicting filesPatrick Steinhardt2018-10-191-14/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding an index entry "a/b/c" while an index entry "a/b" already exists, git will happily remove "a/b/c" and only add the new index entry: $ git init test Initialized empty Git repository in /tmp/test.repo/test/.git/ $ touch x $ git add x $ rm x $ mkdir x $ touch x/y $ git add x/y $ git status A x/y The other way round, adding an index entry "a/b" with an entry "a/b/c" already existing is equivalent, where git will remove "a/b/c" and add "a/b". In contrast, libgit2 will currently fail to add these properly and instead complain about the entry appearing as both a file and a directory. This is a programming error, though: our current code already tries to detect and, in the case of `git_index_add`, to automatically replace such index entries. Funnily enough, we already remove the conflicting index entries, but instead of adding the new entry we then bail out afterwards. This leaves callers with the worst of both worlds: we both remove the old entry but fail to add the new one. The root cause is weird semantics of the `has_file_name` and `has_dir_name` functions. While these functions only sound like they are responsible for detecting such conflicts, they will also already remove them in case where its `ok_to_replace` parameter is set. But even if we tell it to replace such entries, it will return an error code. Fix the error by returning success in case where the entries have been replaced. Fix an already existing test which tested for wrong behaviour. Note that the test didn't notice that the resulting tree had no entries. Thus it is fine to change existing behaviour here, as the previous result could've let to silently loosing data. Also add a new test that verifies behaviour in the reverse conflicting case.
| * index: modernize error handling of `index_insert`Patrick Steinhardt2018-10-191-31/+32
| | | | | | | | | | | | | | | | | | | | The current error hanling of the function `index_insert` is currently very fragile. Instead of erroring out in case an error has happened, it will instead verify that no error has happened for each statement. This makes adding new code to that function an adventurous task. Improve the situation by converting the function to use our typical `goto out` pattern.
* | index: avoid out-of-bounds read when reading reuc entry stagePatrick Steinhardt2018-10-181-1/+1
|/ | | | | | | | | | | We use `git__strtol64` to parse file modes of the index entries, which does not limit the parsed buffer length. As the index can be essentially treated as "untrusted" in that the data stems from the file system, it may be misformatted and may not contain terminating `NUL` bytes. This may lead to out-of-bounds reads when trying to parse index entries with such malformatted modes. Fix the issue by using `git__strntol64` instead.
* index: release the snapshot instead of freeing the indexEtienne Samson2018-09-111-1/+1
| | | | | Previously we would assert in index_free because the reader incrementation would not be balanced. Release the snapshot normally, so the variable gets decremented before the index is freed.
* Fix leak in index.cabyss72018-08-161-1/+2
|
* settings: optional unsaved index safetyEdward Thomson2018-06-291-1/+3
| | | | | | | | | | | | | | Add the `GIT_OPT_ENABLE_UNSAVED_INDEX_SAFETY` option, which will cause commands that reload the on-disk index to fail if the current `git_index` has changed that have not been saved. This will prevent users from - for example - adding a file to the index then calling a function like `git_checkout` and having that file be silently removed from the index since it was re-read from disk. Now calls that would re-read the index will fail if the index is "dirty", meaning changes have been made to it but have not been written. Users can either `git_index_read` to discard those changes explicitly, or `git_index_write` to write them.
* index: return a unique error code on dirty indexEdward Thomson2018-06-291-1/+1
| | | | | When the index is dirty, return GIT_EINDEXDIRTY so that consumers can identify the exact problem programatically.
* index: commit the changes to the index properlyEdward Thomson2018-06-291-0/+11
| | | | | | | Now that the index has a "dirty" state, where it has changes that have not yet been committed or rolled back, our tests need to be adapted to actually commit or rollback the changes instead of assuming that the index can be operated on in its indeterminate state.
* index: add a dirty bit reflecting unsaved changesEdward Thomson2018-06-291-6/+34
| | | | | | | | | | | Teach the index when it is "dirty", and has unsaved changes. Consider the index dirty whenever a caller has added or removed an entry from the main index, REUC or NAME section, including when the index is completely cleared. Similarly, consider the index _not_ dirty immediately after it is written, or when it is read from the on-disk index. This allows us to ensure that unsaved changes are not lost when we automatically refresh the index.
* Convert usage of `git_buf_free` to new `git_buf_dispose`Patrick Steinhardt2018-06-101-9/+9
|
* index: Fix alignment issues in write_disk_entry()John Paul Adrian Glaubitz2018-06-011-21/+21
| | | | | | In order to avoid alignment issues on certain target architectures, it is necessary to use memcpy() when modifying elements of a struct inside a buffer returned by git_filebuf_reserve().
* path: reject .gitmodules as a symlinkCarlos Martín Nieto2018-05-231-4/+5
| | | | | | | | Any part of the library which asks the question can pass in the mode to have it checked against `.gitmodules` being a symlink. This is particularly relevant for adding entries to the index from the worktree and for checking out files.
View Lorry Controller Status