A different bug in git-filter-branch (v2.7.0)

Hi Jeff,

unfortunately, `--tree-filter true` doesn't solve the problem with the repo at my work: not all old blobs are replaced with the new ones. I've made a test repository to demonstrate it; it's a huge one (115M), but I couldn't make it much smaller, because the bug fails to reproduce if the repo is not big enough:

https://github.com/anatolyborodin/git-filter-branch-bug

There are some description and instructions in `README.md`. I hope you will be able to reproduce it on your machine, if not - just add more files :)

I've debugged the test case and found the place where `git diff-index` behaves differently regarding `aa/bb.dat`:

read-cache.c +351	ie_match_stat():
...
	if (!changed && is_racy_timestamp(istate, ce)) {
		if (assume_racy_is_modified)
			changed |= DATA_CHANGED;
		else
			changed |= ce_modified_check_fs(ce, st);
	}
...

After `git-checkout-index` the blob hash for `aa/bb.dat` in the index is 88a0f09b9b2e4ccf2faec89ab37d416fba4ee79d (the huge binary), but the file on disk is a text file "This file was to big, and it has been removed." with the hash 16e0939430610600301680d5bf8a24a22ff8b6c4.

In the case of a "good behaving" commit, the timestamps of the index and the cache entry are the same, is_racy_timestamp() returns 1, and ce_modified_check_fs() finds that the content of the file has changed. `git diff-index` lists the file `aa/bb.dat`.

In the case of a "bad behaving" commit, the timestamps of the index and the cache entry are different (the index is 1 second newer), is_racy_timestamp() returns 0, and the file is assumed unchanged; `git diff-index` prints nothing.

I don't know if it should be considered to be a bug in in the logic of `git checkout-index`, or `git diff-index` / `git update-index`.