git_packbuilder_write() used to write a packfile to the passed file path. Instead, ask for a destination directory and create both the packfile and an index, as most users probably do expect.
This adds ~/ prefix expansion for the value of core.attributesfile and core.excludesfile, plus it fixes the fact that the attributes cache was holding on to the string data from the config for a long time (instead of making its own strdup) which could have caused a problem if the config was refreshed. Adds a test for the new expansion capability.
This improves the docs for GIT_DIFF_INCLUDE_UNTRACKED_CONTENT as well as the other flags related to UNTRACKED items in diff, plus it makes that flag now automatically turn on GIT_DIFF_INCLUDE_UNTRACKED which seems like a reasonable dwim type of change.
The GIT_CONFIG_LEVEL constants actually work well as an enum because they are mutually exclusive, so this adds a typedef to the enum and uses that everywhere that one of these constants are expected, instead of the old code that typically used an unsigned int.
This adds docs for the cache control options to git_libgit2_opts and also tweaks the cache code so that if the cache is disabled, then the next time we attempt to insert something into the cache in question, we will actually clear any old cached objects.
In theory, if there was a problem reading the REUC data, the read_reuc() routine could have left uninitialized and invalid data in the git_index vector. This moves the line that inserts a new entry into the vector down to the bottom of the routine so we know all the content is already valid. Also, per @linquize, this uses calloc to ensure no uninitialized data.
This adds a couple more tests of different rename scenarios. Also, this fixes a problem with the case where you have two "split" deltas and the left half of one matches the right half of the other. That case was already being handled, but in the wrong order in a way that could result in bad output. Also, if the swap also happened to put the other two halves into the correct place (i.e. two files exchanged places with each other), then the second delta was left with the SPLIT flag set when it really should be cleared.
This flips rename detection around so instead of creating a forward mapping from deltas to possible rename targets, instead it creates a reverse mapping, looking at possible targets and trying to find a source that they could have been renamed or copied from. This is important because each output can only have a single source, but a given source could map to multiple outputs (in the form of COPIED records). Additionally, this makes a couple of tweaks to the public rename detection APIs, mostly renaming a couple of options that control the behavior to make more sense and to be more like core Git. I walked through the tests looking at the exact results and updated the expectations based on what I saw. The new code is different from the old because it cannot give some nonsense results (like A was renamed to both B and C) which were part of the outputs previously.