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`. -- Mit freundlichen Grüßen, Anatoly Borodin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
