- 05 Jun, 2020 1 commit
-
-
Edward Thomson committed
-
- 26 May, 2020 1 commit
-
-
The `git_index_free()` merely decrement the reference counter from 2 to 1, and does not "free" the index. Thus, the following `git_repository_index()` merely increase the counter to 2, instead of read index from disk. The written index is not read and parsed, which makes this test case effectively becomes a no-op.
Patrick Wang committed
-
- 07 Feb, 2020 1 commit
-
-
We should always verify error codes returned by function calls in our test suite to not accidentally miss any weird results. Coverity reported missing checks in several locations, which this commit fixes.
Patrick Steinhardt committed
-
- 10 Dec, 2019 6 commits
-
-
Users may want to turn off core.protectNTFS, perhaps to import (and then repair) a broken tree. Ensure that core.protectNTFS=false is honored.
Edward Thomson committed -
Enable core.protectNTFS by default everywhere and in every codepath, not just on checkout.
Edward Thomson committed -
Test that when we enable core.protectNTFS that we cannot add platform-specific invalid paths to the index.
Edward Thomson committed -
The name of the `add_invalid_filename` function suggests that we _want_ to add an invalid filename. Rename the function to show that we expect to _fail_ to add the invalid filename.
Edward Thomson committed -
Ensure that the new protection around .git::$INDEX_ALLOCATION rules are enabled for adding to the index when core.protectNTFS is set.
Edward Thomson committed -
The name of the `write_invalid_filename` function suggests that we _want_ to write an invalid filename. Rename the function to show that we expect to _fail_ to write the invalid filename.
Edward Thomson 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
-
- 18 Jul, 2019 1 commit
-
-
`cvar` is an unhelpful name. Refactor its usage to `configmap` for more clarity.
Patrick Steinhardt committed
-
- 15 Jun, 2019 1 commit
-
-
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.
Edward Thomson committed
-
- 25 Jan, 2019 1 commit
-
-
Cast actual filesystem data to the int32_t that index entries store.
Edward Thomson committed
-
- 24 Jan, 2019 1 commit
-
-
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.
Etienne Samson committed
-
- 22 Jan, 2019 1 commit
-
-
Move to the `git_error` name in the internal API for error-related functions.
Edward Thomson committed
-
- 09 Jan, 2019 1 commit
-
-
This change fixes -Wmaybe-uninitialized and -Wdeprecated-declarations warnings on Linux builds
lhchavez committed
-
- 06 Jan, 2019 2 commits
- 04 Jan, 2019 1 commit
-
-
CID 1398597, 1398598
Etienne Samson committed
-
- 04 Dec, 2018 4 commits
-
-
This is a cherry-pick of the tests from the following commits: core.autocrlf=true and core.safecrlf=true did not fail on LF-only file as vanilla git does Adding a CRLF-file with core.autocrlf=input and core.safecrlf=true does not fail as with vanilla git Make files with #CR!=#CRLF not fail with core.safecrlf=true Reported-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw> Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed -
Don't simply fail when the expected output does not match the data in the index; instead, provide a detailed output about the system, file, and settings that caused the failure so that developers can better isolate the problem(s).
Edward Thomson committed -
Edward Thomson committed
-
Given a variety of combinations of core.autocrlf, core.safecrlf settings and attributes settings, test that we add files to index the same way (regarding OIDs and fatal errors) as a known-good test resource created by git.git. Signed-off-by: Sven Strickroth <email@cs-ware.de>
Sven Strickroth committed
-
- 01 Dec, 2018 2 commits
-
-
Use the new object_type enumeration names within the codebase.
Edward Thomson committed -
Use the new-style index names throughout our own codebase.
Edward Thomson committed
-
- 14 Nov, 2018 1 commit
-
-
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.
Edward Thomson committed
-
- 19 Oct, 2018 1 commit
-
-
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.
Patrick Steinhardt committed
-
- 08 Oct, 2018 1 commit
-
-
When the index does not belong to any repository, we do not do any checks of the target id going in as we cannot verify that it exists. When we then write it out to a repository as a tree, we fail to perform the object existance and type-matching check that we do in other code-paths. This leads to being able to write trees which point to non-existent blobs even with strict object creation enabled.
Carlos Martín Nieto committed
-
- 24 Aug, 2018 1 commit
-
-
Commit 581d5492 (Fix leak in index.c, 2018-08-16) was fixing a memory leak in our code adding conflicts to the index when the added index entries have an invalid file mode. The memory leak was previously undiscovered as there are no tests covering this scenario, which is now being added by this commit.
Patrick Steinhardt committed
-
- 13 Jul, 2018 1 commit
-
-
C++ style comment ("//") are not specified by the ISO C90 standard and thus do not conform to it. While libgit2 aims to conform to C90, we did not enforce it until now, which is why quite a lot of these non-conforming comments have snuck into our codebase. Do a tree-wide conversion of all C++ style comments to the supported C style comments to allow us enforcing strict C90 compliance in a later commit.
Patrick Steinhardt committed
-
- 29 Jun, 2018 4 commits
-
-
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.
Edward Thomson committed -
When the index is dirty, return GIT_EINDEXDIRTY so that consumers can identify the exact problem programatically.
Edward Thomson committed -
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.
Edward Thomson committed -
Test that any changes to the index will mark the index as dirty. Also ensure that when we initialize a new index, read the index contents from disk, or write the index contents to disk that we reset the dirty flag to zero. Further ensure that an unforced read with dirty contents (when the on-disk index has not changed) does _not_ reset the dirty flag as we have not updated the contents of our index and our unsaved contents remain intact.
Edward Thomson committed
-
- 26 Jun, 2018 3 commits
-
-
When running `git_index_add_all`, we should write the index to disk so that we can re-read it safely during status.
Edward Thomson committed -
The index::reuc tests must test that the checkout itself succeeds, otherwise subsequent tests are not valid. In fact, the checkouts were failing because when checking out `SAFE`, they cannot update the files that are in conflict. Change the checkout level to `FORCE` to ensure that they get updated correctly.
Edward Thomson committed -
We add entries into the main index to correspond with the NAME entries that we're going to test. NAME entries store the results of conflicts occuring with rename detection during merge, and they must correspond to conflicts in the index. This test was mistakenly adding regular entries. The checkout validation failed, since it requires NAME entries to correspond to high-stage (conflict) entries. Correct the test to actually create conflicts.
Edward Thomson committed
-
- 10 Jun, 2018 1 commit
-
-
Patrick Steinhardt committed
-
- 19 Feb, 2018 1 commit
-
-
The new index entry structure was not being initialized to all-zeroes. As that structure is used to add a new entry to the current index, and the hashing algorithm of the index making use of the uninitialized flags to calculate the state, we might miscompute the hash of the entry and add it at the wrong position. Later lookups would then fail. Initialize the structure with `memset` to fix the test breaking on some platforms.
Patrick Steinhardt committed
-