Does veracrypt do any sort of file caching in memory that might be preventing changes to my git config files to be recognized?
Long version: I have a repo on a veracrypt partition shared with Windows. While trying to enforce EOL's in my repo, I am seeing files more or less arbitrarily setting EOL's. When making a trivial change to my .gitattributes file, I'll merge this change onto a branch, and suddenly my new branch is filled with files with EOL-only changes.
I'm working on linux using mostly SmartGit or the cmd-line (git v 1.8.3.1). I've tried removed autocrlf and safecrlf or setting to false in both my global and repo config files in case they were confusing things. I've tried deleting my .gitattributes file, or setting
* binary
To prevent any conversion at all.
I have reset dozens of times, and deleted my local repo and re-cloned. But I cannot get rid of these modified files
git rm --cached -r .
git reset --hard
Below is my .gitattributes
# Auto detect text files and perform LF normalization
* text=auto
# Specify LF file endings for coding files
*.txt text eol=lf
*.c text eol=lf
*.cpp text eol=lf
*.h text eol=lf
*.py text eol=lf
*.kl text eol=lf
*.json text eol=lf
# Specify windows-only CRLF endings
*.bat text eol=crlf
*.vcproj text eol=crlf
*.sln text eol=crlf
# Specify binary files - do not modify these files, dammit!
*.so binary
*.dll binary
*.lib binary
*.pdb binary
*.exp binary
*.exe binary
My major problem is that some (not all) .so symlinks are showing up modified in one particular branch - looking for all the world like they've been converted. This consistently occurs in my latest branch, but not earlier branch. In the current spate of madness, my last merge added the *.cpp tag, which promptly converted some (not all) of my *.py files to windows line endings.
Has anyone experienced this kind of unreliability? Is the .gitattributes file supported in this version of git? Is veracrypt or the NTFS partition somehow confusing things on me?
I've been working on what should be a trivial task for a week now, and simply cannot fathom how git is deciding on its EOL strategy.
I still don't know precisely what is going wrong, but I recreated the repo, and as long as I never touch (use it read-only) it in windows it seems ok.