src/index.c


Log

Author Commit Date CI Message
Vicent Marti 91e88941 2010-11-29T18:06:22 Properly write Index Entry 'flags_extended' Always write the 'flags_extended' attribute to disk if it's available. Signed-off-by: Vicent Marti <tanoku@gmail.com>
Vicent Marti c3dd69a9 2010-11-17T04:59:11 Fix resizing the index array No longer segfaults when resizing an empty array. Signed-off-by: Vicent Marti <tanoku@gmail.com>
Vicent Marti c3a20d5c 2010-11-14T22:11:46 Add support for 'index add' Actually add files to the index by creating their corresponding blob and storing it on the repository, then getting the hash and updating the index file. Signed-off-by: Vicent Marti <tanoku@gmail.com>
Scott Chacon 0be42199 2010-11-10T13:43:55 accessor for index entry count
Vicent Marti 3f43678e 2010-11-07T01:24:45 Make the Index API public Several private methods of the Index API are now public, including the methods to remove, get and add index entries. All the methods only take an integer value for the position of the entry to get/remove. To get or remove entries based on their path names, look them up first using the git_index_find method. Signed-off-by: Vicent Marti <tanoku@gmail.com>
Vicent Marti 1795f879 2010-11-05T03:20:17 Improve error handling All initialization functions now return error codes instead of pointers. Error codes are now properly propagated on most functions. Several new and more specific error codes have been added in common.h Signed-off-by: Vicent Marti <tanoku@gmail.com>
Vicent Marti 6fd195d7 2010-11-02T18:42:42 Change git_repository initialization to use a path The constructor to git_repository is now called 'git_repository_open(path)' and takes a path to a git repository instead of an existing ODB object. Unit tests have been updated accordingly and the two test repositories have been merged into one. Signed-off-by: Vicent Marti <tanoku@gmail.com>
Vicent Marti 68535125 2010-07-09T20:19:56 Add support for git index files The new 'git_index' structure is an in-memory representation of a git index on disk; the 'git_index_entry' structures represent each one of the file entries on the index. The following calls for index instantiation have been added: git_index_alloc(): instantiate a new index structure git_index_free(): free an existing index git_index_clear(): clear all the entires in an existing file The following calls for index reading and writing have been added: git_index_read(): update the contents of the index structure from its file on disk. Internally implemented through: git_index__parse() Index files are stored on disk in network byte order; all integer fields inside them are properly converted to the machine's byte order when loading them in memory. The parsing engine also distinguishes between normal index entries and extended entries with 2 extra bytes of flags. The 'TREE' extension for index entries is also loaded into memory: Tree caches stored in Index files are loaded into the 'git_index_tree' structure pointed by the 'tree' pointer inside 'git_index'. 'index->tree' points to the root node of the tree cache; the full tree can be traversed through each of the node's 'tree->children'. Index files can be written back to disk through: git_index_write(): atomic writing of existing index objects backed by internal method git_index__write() The following calls for entry manipulation have been added: git_index_add(): insert an empty entry to the index git_index_find(): search an entry by its path name git_index__append(): appends a new index entry to the end of the list, resizing the entries array if required New index entries are always inserted at the end of the array; since the index entries must be sorted for it to be internally consistent, the index object is only sorted once, and if required, before accessing the whole entriea array (e.g. before writing to disk, before traversing, etc). git_index__remove_pos(): remove an index entry in a specific position git_index__sort(): sort the entries in the array by path name The entries array is sorted stably and in place using an insertion sort, which ought to be the most efficient approach since the entries array is always mostly-sorted. Signed-off-by: Vicent Marti <tanoku@gmail.com>