- 28 Feb, 2016 1 commit
-
-
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
-
- 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
-
- 19 Sep, 2015 1 commit
-
-
Axel Rasmussen committed
-
- 29 Jun, 2015 1 commit
-
-
Edward Thomson committed
-
- 26 Jun, 2015 1 commit
-
-
Carlos Martín Nieto committed
-
- 22 Jun, 2015 5 commits
-
-
Even though the file is empty and thus the size in the entry matches, we should be able to detect it as a difference.
Carlos Martín Nieto committed -
They fit there much better, even though we often check by diffing, it's about the behaviour of the index.
Carlos Martín Nieto committed -
Carlos Martín Nieto committed
-
Carlos Martín Nieto committed
-
When a file on the workdir has the same or a newer timestamp than the index, we need to perform a full check of the contents, as the update of the file may have happened just after we wrote the index. The iterator changes are such that we can reach inside the workdir iterator from the diff, though it may be better to have an accessor instead of moving these structs into the header.
Carlos Martín Nieto committed
-
- 16 Jun, 2015 1 commit
-
-
We update the index and then immediately change the contents of the file. This makes the diff think there are no changes, as the timestamp of the file agrees with the cached data. This is however a bug, as the file has obviously changed contents. The test is a bit fragile, as it assumes that the index writing and the following modification of the file happen in the same second, but it's enough to show the issue.
Carlos Martín Nieto committed
-