We have various macro, enumeration and structure names that were introduced (very) early in the project and do not match our current naming conventions. For instance: `GIT_IDXENTRY...` flags that correspond to a structure named `git_index_entry`. Update these to match the current guidance. The old macros and enumeration names are reflected as new macros in order to support backward compatibility (and do so without warnings for consumers).
Provide a public git_index_iterator API that is backed by an index snapshot. This allows consumers to provide a stable iteration even while manipulating the index during iteration.
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>
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.
Find the first index entry matching a prefix.
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.
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.
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.
While we are confident about the size of an int in architectures we're likely to care about, the index format is defined by the exact size of the fields. Use the definitions which show the exact width of the entry fields. As part of that, bring back 32-bit time and size fields, which currently are 64 bits wide and can bring a false sense of security in how much data they really store. Document that these fields are not to be taken as authoritative.