git-fat behaves unexpectedly after performing "cp -a" on the repository

[rwh21]

If I run "cp -a" to make a copy of the entire git repository, and I'm using git-fat, some unexpected behaviour is displayed: If I run "git status" on the copy I have made, it reports a number of modified files that weren't modified in the original repository.

What seems to be happening is that git-fat re-evaluates any large files that are stored directly in git, e.g. legacy files from before I started using git-fat, and moves them into the fat store.

I understand from reading the docs that git-fat is supposed to consider only new or modified files for inclusion into the fat store, and leave existing files alone. It seems that copying the repository with "cp -a" makes git-fat think that the files are new.

The steps to reproduce this are as follows:-

1. Create a git repository.
2. Commit some .tar.gz files.
3. Set up git-fat, with a valid .gitfat file, remote store, and a .gitattributes file containing *.tar.gz.
4. Commit the .gitfat and .gitattributes files.
5. Run "git status" to check that there are no uncommitted changes.
6. Use "cp -a" to take a copy of the repository: cp -a repository repository.copy
7. cd repository.copy
8. "git status" says that all the .tar.gz files committed in step (2) are modified.

Simply renaming the repository doesn't cause the issue. It's happens only when I copy the repository.

[jedbrown]

I'm afraid I don't have time to reproduce right now (end of the semester and conference), but this sounds like an artifact of the way Git handles smudge/clean filters. I know there have been changes in the most recent version of Git, so that might help/hurt. Does git checkout -f . help?

[rwh21]

Thank you for your reply. I tried the latest version of git (2.11.0.22.g8d7a455), but this doesn't appear to have made any difference. I also tried git checkout -f. This did make a difference, and the results were surprising: it reduced the number of files being reported as "modified" to a much smaller number, but never zero. Repeating the test several times, the result was different each time. I am confused by this randomness.
"git checkout -f ." has an effect the first time it runs, but if I run it multiple times in the same repository the number of modified files remains the same.

[jedbrown]

Probably git fat checkout then. I'm not aware of anything git-fat could do to fix this before git status gives you confusing output. Git decides when to run the filters unless git-fat is called manually and does something expensive.