summaryrefslogtreecommitdiff
path: root/src/index.c
Commit message (Collapse)AuthorAgeFilesLines
* index: get rid of the lockingcmn/index-nolockCarlos Martín Nieto2015-12-281-130/+15
| | | | | | | We don't support using an index object from multiple threads at the same time, so the locking doesn't have any effect when following the rules. If not following the rules, things are going to break down anyway.
* index: Also size-hint the hash tablevmg/index-fill-2Vicent Marti2015-12-161-4/+2
| | | | | | | Note that we're not checking whether the resize succeeds; in OOM cases, we let it run with a "small" vector and hash table and see if by chance we can grow it dynamically as we insert the new entries. Nothing to lose really.
* index: Preallocate the entries vector with size hintVicent Marti2015-12-161-0/+8
|
* index: Adjust namemask & mode when fillingVicent Marti2015-12-161-14/+17
|
* merge: Use `git_index__fill` to populate the indexvmg/index-fillVicent Marti2015-12-161-0/+37
| | | | | | | | | | | | | Instead of calling `git_index_add` in a loop, use the new `git_index_fill` internal API to fill the index with the initial staged entries. The new `fill` helper assumes that all the entries will be unique and valid, so it can append them at the end of the entries vector and only sort it once at the end. It performs no validation checks. This prevents the quadratic behavior caused by having to sort the entries list once after every insertion.
* Merge pull request #3538 from pks-t/pks/index-memory-leakCarlos Martín Nieto2015-12-101-1/+1
|\ | | | | index: always queue `remove_entry` for removal
| * index: always queue `remove_entry` for removalPatrick Steinhardt2015-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When replacing an index with a new one, we need to iterate through all index entries in order to determine which entries are equal. When it is not possible to re-use old entries for the new index, we move it into a list of entries that are to be removed and thus free'd. When we encounter a non-zero error code, though, we skip adding the current index entry to the remove-queue. `INSERT_MAP_EX`, which is the function last run before adding to the remove-queue, may return a positive non-zero code that indicates what exactly happened while inserting the element. In this case we skip adding the entry to the remove-queue but still continue the current operation, leading to a leak of the current entry. Fix this by checking for a negative return value instead of a non-zero one when we want to add the current index entry to the remove-queue.
* | index: canonicalize inserted paths safelyEdward Thomson2015-12-031-1/+1
|/ | | | | | | | | | | | | | | | | | When adding to the index, we look to see if a portion of the given path matches a portion of a path in the index. If so, we will use the existing path information. For example, when adding `foo/bar.c`, if there is an index entry to `FOO/other` and the filesystem is case insensitive, then we will put `bar.c` into the existing tree instead of creating a new one with a different case. Use `strncmp` to do that instead of `memcmp`. When we `bsearch` into the index, we locate the position where the new entry would go. The index entry at that position does not necessarily have a relation to the entry we're adding, so we cannot make assumptions and use `memcmp`. Instead, compare them as strings. When canonicalizing paths, we look for the first index entry that matches a given substring.
* checkout: only consider nsecs when built that wayEdward Thomson2015-11-231-17/+3
| | | | | | | | When examining the working directory and determining whether it's up-to-date, only consider the nanoseconds in the index entry when built with `GIT_USE_NSEC`. This prevents us from believing that the working directory is always dirty when the index was originally written with a git client that uinderstands nsecs (like git 2.x).
* racy: make git_index_read_index handle racinessEdward Thomson2015-11-161-30/+48
| | | | | | | | | | | 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.
* index: clear uptodate bit on saveEdward Thomson2015-11-161-1/+16
| | | | | | The uptodate bit should have a lifecycle of a single read->write on the index. Once the index is written, the files within it should be scanned for racy timestamps against the new index timestamp.
* index: don't detect raciness in uptodate entriesEdward Thomson2015-11-161-2/+7
| | | | | | | | | | | 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.
* racy-git: do a single index->workdir diffEdward Thomson2015-11-161-10/+23
| | | | | | When examining paths that are racily clean, do a single index->workdir diff over the entirety of the racily clean files, instead of a diff per file.
* Merge pull request #3170 from CmdrMoozy/nsec_fixCarlos Martín Nieto2015-11-121-9/+19
|\ | | | | git_index_entry__init_from_stat: set nsec fields in entry stats
| * diff/index: respect USE_NSEC for racily clean file detectionAxel Rasmussen2015-09-181-7/+15
| |
| * cmake: Only provide USE_NSEC if struct stat members are avilable.Axel Rasmussen2015-09-181-2/+1
| | | | | | | | | | | | This allows us to remove OS checks from source code, instead relying on CMake to detect whether or not `struct stat` has the nanoseconds members we rely on.
| * cmake: add USE_NSEC, and only check nanosec m/ctime if enabledAxel Rasmussen2015-09-181-2/+5
| |
* | index: overwrite the path when inserting conflictsntk/case_index_conflictsCarlos Martín Nieto2015-11-121-1/+1
| | | | | | | | | | | | | | | | | | When we insert a conflict in a case-insensitive index, accept the new entry's path as the correct case instead of leaving the path we already had. This puts `git_index_conflict_add()` on the same level as `git_index_add()` in this respect.
* | index: correctly report which conflict stage has a wrong filemodeCarlos Martín Nieto2015-11-121-1/+1
| | | | | | | | | | When we're at offset 'i', we're dealing with the 'i+1' stage, since conflicts start at 1.
* | index: read_index must update hashesEdward Thomson2015-10-301-9/+29
| |
* | pool: Simplify implementationVicent Marti2015-10-281-1/+1
| |
* | reuc: Be smarter when inserting new REUC entriesVicent Marti2015-10-271-19/+16
| | | | | | | | | | | | | | | | | | | | Inserting new REUC entries can quickly become pathological given that each insert unsorts the REUC vector, and both subsequent lookups *and* insertions will require sorting it again before being successful. To avoid this, we're switching to `git_vector_insert_sorted`: this keeps the REUC vector constantly sorted and lets us use the `on_dup` callback to skip an extra binary search on each insertion.
* | index: Remove unneeded constsVicent Marti2015-10-211-3/+3
| |
* | index: also try conflict mode when insertingEdward Thomson2015-09-301-15/+62
|/ | | | | | | | | | When we do not trust the on-disk mode, we use the mode of an existing index entry. This allows us to preserve executable bits on platforms that do not honor them on the filesystem. If there is no stage 0 index entry, also look at conflicts to attempt to answer this question: prefer the data from the 'ours' side, then the 'theirs' side before falling back to the common ancestor.
* Merge pull request #3353 from ethomson/wrongcase_addCarlos Martín Nieto2015-09-081-22/+114
|\ | | | | index: canonicalize directory case when adding
| * git_index_add: allow case changing renamesEdward Thomson2015-09-081-15/+26
| | | | | | | | | | | | | | | | | | | | | | On case insensitive platforms, allow `git_index_add` to provide a new path for an existing index entry. Previously, we would maintain the case in an index entry without the ability to change it (except by removing an entry and re-adding it.) Higher-level functions (like `git_index_add_bypath` and `git_index_add_frombuffers`) continue to keep the old path for easier usage.
| * index: canonicalize directory case when addingEdward Thomson2015-09-081-7/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On case insensitive systems, when given a user-provided path in the higher-level index addition functions (eg `git_index_add_bypath` / `git_index_add_frombuffer`), examine the index to try to match the given path to an existing directory. Various mechanisms can cause the on-disk representation of a folder to not match the representation in HEAD or the index - for example, a case changing rename of some file `a/file.txt` to `A/file.txt` will update the paths in the index, but not rename the folder on disk. If a user subsequently adds `a/other.txt`, then this should be stored in the index as `A/other.txt`.
* | Merge pull request #3381 from leoyanggit/index_directory_iteratorEdward Thomson2015-09-081-0/+24
|\ \ | |/ |/| New feature: add the ablility to iterate through a directory in index
| * New API: git_index_find_prefixLeo Yang2015-09-041-0/+24
| | | | | | | | Find the first index entry matching a prefix.
* | Merge pull request #3366 from libgit2/cmn/index-hashmapEdward Thomson2015-09-061-17/+99
|\ \ | |/ |/| Use a hashmap for path-based lookups in the index
| * index: put the icase insert choice in macroscmn/index-hashmapCarlos Martín Nieto2015-09-041-25/+30
| | | | | | | | | | This should let us see more clearly what we're doing and avoid the ugly 'if' we need every time we want to interact with the map.
| * index: keep a hash table as well as a vector of entriesCarlos Martín Nieto2015-08-141-17/+94
| | | | | | | | | | The hash table allows quick lookup of specific paths, while we use the vector for enumeration.
* | racy-git: TODO to use improved diffingEdward Thomson2015-08-281-0/+1
| |
* | iterator: use an options struct instead of argsEdward Thomson2015-08-281-4/+5
|/
* errors: tighten up git_error_state OOMs a bit moreEdward Thomson2015-08-031-3/+3
| | | | | When an error state is an OOM, make sure that we treat is specially and do not try to free it.
* index: stage an unregistered submodule as wellcmn/add-unreg-submoduleCarlos Martín Nieto2015-08-011-5/+58
| | | | | | We previously added logic to `_add_bypath()` to update a submodule. Go further and stage the submodule even if it's not registered to behave like git.
* index: allow add_bypath to update submodulescmn/index-add-submoduleCarlos Martín Nieto2015-07-121-2/+22
| | | | | Similarly to how git itself does it, allow the index update operation to stage a change in a submodule's HEAD.
* index: check racily clean entries more thoroughlyCarlos Martín Nieto2015-06-221-2/+41
| | | | | | When an entry has a racy timestamp, we need to check whether the file itself has changed since we put its entry in the index. Only then do we smudge the size field to force a check the next time around.
* index: make relative comparison use the checksum as wellcmn/index-checksumCarlos Martín Nieto2015-06-201-4/+2
| | | | | | This is used by the submodule in order to figure out if the index has changed since it last read it. Using a timestamp is racy, so let's make it use the checksum, just like we now do for reloading the index itself.
* index: use the checksum to check whether it's been modifiedCarlos Martín Nieto2015-06-191-5/+42
| | | | | | | | | | | | | We currently use a timetamp to check whether an index file has been modified since we last read it, but this is racy. If two updates happen in the same second and we read after the first one, we won't detect the second one. Instead read the SHA-1 checksum of the file, which are its last 20 bytes which gives us a sure-fire way to detect whether the file has changed since we last read it. As we're now keeping track of it, expose an accessor to this data.
* index: zero the size of racily-clean entriesCarlos Martín Nieto2015-06-161-0/+18
| | | | | | | | | | | | | | | | If a file entry has the same timestamp as the index itself, it is considered racily-clean, as it may have been modified after the index was written, but during the same second. We take extra steps to check the contents, but this is just one part of avoiding races. For files which do have changes but have not been updated in the index, updating the on-disk index means updating its timestamp, which means we would no longer recognise these entries as racy and we would trust the timestamp to tell us whether they have changed. In order to work around this, git zeroes out the file-size field in entries with the same timestamp as the index in order to force the next diff to check the contents. Do so in libgit2 as well.
* diff: introduce binary diff callbacksEdward Thomson2015-06-121-1/+1
| | | | | | | Introduce a new binary diff callback to provide the actual binary delta contents to callers. Create this data from the diff contents (instead of directly from the ODB) to support binary diffs including the workdir, not just things coming out of the ODB.
* index_add_all: remove conflicts when no wd fileEdward Thomson2015-05-281-1/+2
| | | | | | | If there exists a conflict in the index, but no file in the working directory, this implies that the user wants to accept the resolution by removing the file. Thus, remove the conflict entry from the index, instead of trying to add a (nonexistent) file.
* introduce `git_index_entry_is_conflict`Edward Thomson2015-05-281-1/+6
| | | | | | | | | It's not always obvious the mapping between stage level and conflict-ness. More importantly, this can lead otherwise sane people to write constructs like `if (!git_index_entry_stage(entry))`, which (while technically correct) is unreadable. Provide a nice method to help avoid such messy thinking.
* index: validate mode of new conflictsEdward Thomson2015-05-281-0/+9
|
* index: remove error message in non-error removeEdward Thomson2015-05-281-0/+3
| | | | | If `git_index_remove_bypath` does no work, and returns an OK error code, it should not set an error message.
* conflicts: when adding conflicts, remove stagedEdward Thomson2015-05-281-1/+16
| | | | | | When adding a conflict for some path, remove the staged entry. Otherwise, an illegal index (with both stage 0 and high-stage entries) would result.
* git_index_add_all: don't recurse ignored dirsEdward Thomson2015-05-201-2/+1
| | | | | No need to get reports about individual ignored files, having a single ignored directory delta is enough.
* index_add_all: include untracked files in new subdirsEdward Thomson2015-05-201-1/+4
|
* index: include TYPECHANGE in the diffCarlos Martín Nieto2015-05-141-1/+2
| | | | Without this option, we would not be able to catch exec bit changes.