2.19 Index

If a previous index entry exists that has the same path and stage as the given ’source_entry’, it will be replaced. Otherwise, the ’source_entry’ will be added.

A full copy (including the ’path’ string) of the given ’source_entry’ will be inserted on the index.

This method will fail in bare index instances.

The pathspec is a list of file names or shell glob patterns that will matched against files in the repository’s working directory. Each file that matches will be added to the index (either updating an existing entry or adding a new entry). You can disable glob expansion and force exact matching with the GIT_INDEX_ADD_DISABLE_PATHSPEC_MATCH flag.

Files that are ignored will be skipped (unlike git_index_add_bypath). If a file is already tracked in the index, then it will be updated even if it is ignored. Pass the GIT_INDEX_ADD_FORCE flag to skip the checking of ignore rules.

To emulate git add -A and generate an error if the pathspec contains the exact path of an ignored file (when not using FORCE), add the GIT_INDEX_ADD_CHECK_PATHSPEC flag. This checks that each entry in the pathspec that is an exact match to a filename on disk is either not ignored or already in the index. If this check fails, the function will return GIT_EINVALIDSPEC.

To emulate git add -A with the "dry-run" option, just use a callback function that always returns a positive value. See below for details.

If any files are currently the result of a merge conflict, those files will no longer be marked as conflicting. The data about the conflicts will be moved to the "resolve undo" (REUC) section.

If you provide a callback function, it will be invoked on each matching item in the working directory immediately before it is added to / updated in the index. Returning zero will add the item to the index, greater than zero will skip the item, and less than zero will abort the scan and return that value to the caller.

The file path must be relative to the repository’s working folder and must be readable.

This method will fail in bare index instances.

This forces the file to be added to the index, not looking at gitignore rules. Those rules can be evaluated through the git_status APIs (in status.h) before calling this.

If this file currently is the result of a merge conflict, this file will no longer be marked as conflicting. The data about the conflict will be moved to the "resolve undo" (REUC) section.

This method will create a blob in the repository that owns the index and then add the index entry to the index. The path of the entry represents the position of the blob relative to the repository’s root folder.

If a previous index entry exists that has the same path as the given ’entry’, it will be replaced. Otherwise, the ’entry’ will be added. The id and the file_size of the ’entry’ are updated with the real value of the blob.

This forces the file to be added to the index, not looking at gitignore rules. Those rules can be evaluated through the git_status APIs (in status.h) before calling this.

If this file currently is the result of a merge conflict, this file will no longer be marked as conflicting. The data about the conflict will be moved to the "resolve undo" (REUC) section.

This checksum is the SHA-1 hash over the index file (except the last 20 bytes which are the checksum itself). In cases where the index does not exist on-disk, it will be zeroed out.

This clears the index object in memory; changes must be explicitly written to disk for them to take effect persistently.

The entries are the entries from the tree included in the merge. Any entry may be null to indicate that that file was not present in the trees during the merge. For example, ancestor_entry may be NULL to indicate that a file was added in both branches and must be resolved.

The entries are not modifiable and should not be freed. Because the git_index_entry struct is a publicly defined struct, you should be able to make your own permanent copy of the data if necessary.

Returns (values (ancestor_out : index_entry?) (our_out : index_entry?) (their_out : index_entry?)). See Multiple Values

The index must not be modified while iterating; the results are undefined.

Returns (values (ancestor_out : index_entry?) (our_out : index_entry?) (their_out : index_entry?)). See Multiple Values

This entry is calculated from the entry’s flag attribute like this:

(entry->flags & GIT_IDXENTRY_STAGEMASK) >> GIT_IDXENTRY_STAGESHIFT

The entry is not modifiable and should not be freed. Because the git_index_entry struct is a publicly defined struct, you should be able to make your own permanent copy of the data if necessary.

The entry is not modifiable and should not be freed. Because the git_index_entry struct is a publicly defined struct, you should be able to make your own permanent copy of the data if necessary.

This index object cannot be read/written to the filesystem, but may be used to perform in-memory index operations.

The index must be freed once it’s no longer in use.

Since there is no ODB or working directory behind this index, any Index methods which rely on these (e.g. index_add_bypath) will fail with the GIT_ERROR error code.

If you need to access the index of an actual repository, use the git_repository_index wrapper.

The index must be freed once it’s no longer in use.

If force is true, this performs a "hard" read that discards in-memory changes and always reloads the on-disk index data. If there is no on-disk version, the index will be cleared.

If force is false, this does a "soft" read that reloads the index data from disk only if it has changed since the last time it was loaded. Purely in-memory index data will be untouched. Be aware: if there are changes on disk, unwritten in-memory changes are discarded.

The current index contents will be replaced by the specified tree.

If you provide a callback function, it will be invoked on each matching item in the index immediately before it is removed. Return 0 to remove the item, > 0 to skip the item, and < 0 to abort the scan.

The file path must be relative to the repository’s working folder. It may exist.

If this file currently is the result of a merge conflict, this file will no longer be marked as conflicting. The data about the conflict will be moved to the "resolve undo" (REUC) section.

If you pass GIT_INDEXCAP_FROM_OWNER for the caps, then the capabilities will be read from the config of the owner object, looking at core.ignorecase, core.filemode, core.symlinks.

Valid values are 2, 3, or 4. If 2 is given, git_index_write may write an index with version 3 instead, if necessary to accurately represent the index.

This method will fail in bare index instances.

This scans the existing index entries and synchronizes them with the working directory, deleting them if the corresponding working directory file no longer exists otherwise updating the information (including adding the latest version of file to the ODB if needed).

If you provide a callback function, it will be invoked on each matching item in the index immediately before it is updated (either refreshed or removed depending on working directory state). Return 0 to proceed with updating the item, > 0 to skip the item, and < 0 to abort the scan.

Valid return values are 2, 3, or 4. If 3 is returned, an index with version 2 may be written instead, if the extension data in version 3 is not necessary.

This method will scan the index and write a representation of its current state back to disk; it recursively creates tree objects for each of the subtrees stored in the index, but only returns the OID of the root tree. This is the OID that can be used e.g. to create a commit.

The index instance cannot be bare, and needs to be associated to an existing repository.

The index must not contain any file in conflict.

This method will do the same as git_index_write_tree, but letting the user choose the repository where the tree will be written.

The index must not contain any file in conflict.