Test a rebase (both a merge rebase and an inmemory rebase) with a new commit that adds files underneath a new subfolder.
Use legitimate (existing) object IDs in tests so that we have the ability to turn on strict object validation when running tests.
Introduce a repository that contains some paths that were illegal on PC-DOS circa 1981 (like `aux`, `con`, `com1`) and that in a bizarre fit of retrocomputing, remain illegal on some "modern" computers, despite being "new technology". Introduce some aspirational tests that suggest that we should be able to cope with trees and indexes that contain paths that would be illegal on the filesystem, so that we can at least diff them. Further ensure that checkout will not write a repository with forbidden paths.
Line count overflow in git_blame_hunk and git_blame__entry
When formatting a patch as email we do not include the commit's message in the formatted patch output. Implement this and add a test that verifies behavior.
It is not unreasonable to have versioned files with a line count exceeding 2^16. Upon blaming such files we fail to correctly keep track of the lines as `git_blame_hunk` stores them in `uint16_t` fields. Fix this by converting the line fields of `git_blame_hunk` to `size_t`. Add test to verify behavior.
When building a recursive merge base, allow conflicts to occur. Use the file (with conflict markers) as the common ancestor. The user has already seen and dealt with this conflict by virtue of having a criss-cross merge. If they resolved this conflict identically in both branches, then there will be no conflict in the result. This is the best case scenario. If they did not resolve the conflict identically in the two branches, then we will generate a new conflict. If the user is simply using standard conflict output then the results will be fairly sensible. But if the user is using a mergetool or using diff3 output, then the common ancestor will be a conflict file (itself with diff3 output, haha!). This is quite terrible, but it matches git's behavior.