Interesting. This being a problem with caching of submodule data makes sense.

When I was writing the submodule code, I was really worried that a lot of the operations were going to be expensive, so I built up a submodule list in memory and tried to store everything that we can discern about the submodules into that data structure. In retrospect, the design is too aggressive about keeping stuff in memory without having good controls to ensure things are synchronized with the disk.

I'll see if I can make some contributions to this branch to get this on track...

Ok, so the issue here was not that the test didn't look at the diff output of UNMODIFIED items; the issue in the tests was that those records should not have been UNMODIFIED and the tests didn't validate that there was no expected output for an UNMODIFIED record.

I updated the tests with a somewhat different validation and fixed the problem that was incorrectly marking dirty submodules as UNMODIFIED.

This facet of things doesn't really have anything to do with caching. When I reorganized the diff code recently, I moved the check that looked if a file was actually unmodified post data-load and accidentally made it too aggressive in clearing the MODIFIED state.

That being said, I suspect there are still some issues with overly aggressive submodule caching and I'll keep looking at that. @jspahrsummers Do you want to get this fix merged ASAP or do you want to wait for me to add tests that try to show the submodule cache being used while invalid?

Just a quick status update before I have to go offline for a couple hours.

I've written an additional test that focuses on one submodule and makes a series of changes to the contents of that module while repeatedly diffing using various values with git_submodule_set_ignore(). It actually performed better than I expected, picking up the addition of an untracked file to the submodule working directory, the modification of a tracked file in the submodule, and the addition of that modification to the submodule index all without any caching issues..

The one case where the cache seems to be screwing up is when I then generate a new commit from that updated index actually moving the HEAD of the submodule. It seems that we cache the old HEAD oid and don't pick up on the modification. I'm pretty sure I know a good way to fix this, but I haven't fixed it yet.

I'm going to hold off on pushing my new failing test up here in case you decide you want to merge this PR that fixes the UNMODIFIED issue and have me deal with the caching issue in a separate PR.

Awesome! Yeah, I'd love to get the diff fix in ASAP. The caching isn't as pressing right now.

Okay, let's just merge this as a priority bug fix and I'll open a new PR with fixes for the caching stuff (which is going to be a much larger change to the test suite and more intrusive fix anyhow).