- 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
-
- 18 Feb, 2018 1 commit
-
-
Ensure that the buffer given to `git_index_add_frombuffer` represents a regular blob, an executable blob, or a link. Explicitly reject commit entries (submodules) - it makes little sense to allow users to add a submodule from a string; there's no possible path to success.
Edward Thomson committed
-
- 23 Jun, 2017 1 commit
-
-
The test `index::tests::can_lock_index` operates on the "testrepo.git" repository located inside of our source tree. While this is okay for tests which do read-only operations on these resouces, this specific test tries to lock the index by creating a lock. This will obviously fail on out-of-tree builds with read-only source trees. Fix the issue by creating a sandbox first.
Patrick Steinhardt committed
-
- 06 Jun, 2017 4 commits
-
-
The current write test does not trigger some edge-cases in the index version 4 path compression code. Rewrite the test to start off the an empty standard repository, creating index entries with interesting paths itself. This allows for more fine-grained control over checked paths. Furthermore, we now also verify that entry paths are actually reconstructed correctly.
Patrick Steinhardt committed -
While we do have a test which checks whether a written index of version 4 has the correct version set, we do not check whether this actually enables path compression for index entries. This commit adds a new test by adding a number of index entries with equal path prefixes to the index and subsequently flushing that to disk. With suffix compression enabled by index version 4, only the last few bytes of these paths will actually have to be written to the index, saving a lot of disk space. For the test, differences are about an order of magnitude, allowing us to easily verify without taking a deeper look at actual on-disk contents.
Patrick Steinhardt committed -
While we have a simple test to determine whether we can write an index of version 4, we never verified that we are able to read this kind of index (and in fact, we were not able to do so). Add a new repository which has an index of version 4. This repository is then read from a new test.
Patrick Steinhardt committed -
The init and cleanup functions for test suites are usually prepended to our actual tests. The index::version test suite does not adhere to this stile. Fix this.
Patrick Steinhardt committed
-
- 29 Aug, 2016 1 commit
-
-
Plug a memory leak caused by re-allocating a `git_index` structure which has already been allocated by the test suite's initializer.
Patrick Steinhardt committed
-
- 10 Aug, 2016 1 commit
-
-
Support reading and writing index v4. Index v4 uses a very simple compression scheme for pathnames, but is otherwise similar to index v3. Signed-off-by: David Turner <dturner@twitter.com>
David Turner committed
-
- 06 Aug, 2016 1 commit
-
-
Edward Thomson committed
-
- 29 Jun, 2016 1 commit
-
-
Ensure that we include conflicts when calling `git_index_read_index`, which will remove conflicts in the index that do not exist in the new target, and will add conflicts from the new target.
Edward Thomson committed
-
- 02 Jun, 2016 2 commits
-
-
Read a tree into an index, write the index, then re-open the index and ensure that we are treesame to the original.
Edward Thomson committed -
Read a tree into an index using `git_index_read_index` (by reading a tree into a new index, then reading that index into the current index), then write the index back out, ensuring that our new index is treesame to the tree that we read.
Edward Thomson committed
-
- 11 Mar, 2016 1 commit
-
-
git_buf_clear does not free allocated memory associated with a git_buf. Use `git_buf_free` instead to correctly free its memory and plug the memory leak.
Patrick Steinhardt committed
-
- 08 Mar, 2016 1 commit
-
-
Instead of hoping that we can get a racy entry by going real fast and praying real hard, just create a racy entry.
Edward Thomson committed
-
- 07 Mar, 2016 1 commit
-
-
If the underlying filesystem doesn't support better than one second resolution, then don't expect that turning on `GIT_USE_NSEC` does anything magical to change that.
Edward Thomson committed
-
- 28 Feb, 2016 3 commits
-
-
Edward Thomson committed
-
Use legitimate (existing) object IDs in tests so that we have the ability to turn on strict object validation when running tests.
Edward Thomson committed -
When `GIT_OPT_ENABLE_STRICT_OBJECT_CREATION` is turned on, validate the index entries given to `git_index_add`.
Edward Thomson committed
-
- 25 Feb, 2016 1 commit
-
-
The index::nsec::staging_maintains_other_nanos test was created to ensure that when we stage an entry when GIT_USE_NSECS is *unset* that we truncate the index entry and do not persist the (old, invalid) nanosec values. Ensure that when GIT_USE_NSECS is *set* that we do not do that, and actually write the correct nanosecond values.
Edward Thomson committed
-
- 12 Feb, 2016 1 commit
-
-
Windows defines `timeval` with `long`, which we cannot sanely cope with. Instead, use a custom timeval struct.
Edward Thomson committed
-
- 21 Dec, 2015 1 commit
-
-
Dmitriy Olshevskiy committed
-
- 30 Nov, 2015 1 commit
-
-
Patrick Steinhardt committed
-
- 20 Nov, 2015 1 commit
-
-
Jacques Germishuys committed
-
- 17 Nov, 2015 4 commits
-
-
Ensure that `git_index_read_index` clears the uptodate bit on files that it modifies. Further, do not propagate the cache from an on-disk index into another on-disk index. Although this should not be done, as `git_index_read_index` is used to bring an in-memory index into another index (that may or may not be on-disk), ensure that we do not accidentally bring in these bits when misused.
Edward Thomson committed -
Ensure that `git_index_read_tree` clears the uptodate bit on files that it modifies.
Edward Thomson committed -
Test that entries are only smudged when we write the index: the entry smudging is to prevent us from updating an index in a way that it would be impossible to tell that an item was racy. Consider when we load an index: any entries that have the same (or newer) timestamp than the index itself are considered racy, and are subject to further scrutiny. If we *save* that index with the same entries that we loaded, then the index would now have a newer timestamp than the entries, and they would no longer be given that additional scrutiny, failing our racy detection! So test that we smudge those entries only on writing the new index, but that we can detect them (in diff) without having to write.
Edward Thomson committed -
Keep track of entries that we believe are up-to-date, because we added the index entries since the index was loaded. This prevents us from unnecessarily examining files that we wrote during the cleanup of racy entries (when we smudge racily clean files that have a timestamp newer than or equal to the index's timestamp when we read it). Without keeping track of this, we would examine every file that we just checked out for raciness, since all their timestamps would be newer than the index's timestamp.
Edward Thomson committed
-
- 12 Nov, 2015 1 commit
-
-
nulltoken committed
-
- 03 Nov, 2015 1 commit
-
-
Test that on platforms without `core.symlinks`, we preserve symlinks in `git_index_add_bypath`. (Users should correct the actual index entry's mode to change a link to a regular file.)
Edward Thomson committed
-