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.
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.
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).
The hash table allows quick lookup of specific paths, while we use the vector for enumeration.
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.
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.
Provide git_indexwriter_init_for_operation for the common locking pattern in merge, rebase, revert and cherry-pick.
Introduce `git_indexwriter`, to allow us to lock the index while performing additional operations, then complete the write (or abort, unlocking the index).