Please describe the problem.
git commit smudges unlocked files in the index when they were already smudged with git status.
What steps will reproduce the problem?
for i in {1..200}; do echo $i > $i; done
git init; git annex init; git config annex.thin true; git config annex.crippledfilesystem true; git config annex.addunlocked true; git annex add .; git status; time git commit -m .
git commit should take less than a second but takes several seconds to smudge the files in the index.
What version of git-annex are you using? On what operating system?
Through bisection, the problem was found to be introduced in 428c91606b434512d1986622e751c795edf4df44. Problem occurs both in Linux and WSL1.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
git-annex has worked wonderfully for managing my files across different machines and cloud storage services.
I doubt this bisection was correct. Whether git commit decides to smudge a file is entirely an internal decision on the part of git; the only way git-annex can affect it is by updating the mtime etc of the file.
Even small things like variations in timing can change git's smudging behavior. It may unncessarily re-smudge a file when its timestamp is sufficiently close to the current time. For whatever internal value of "sufficiently close" it happens to pick for a given OS/filesystem/whatever.
While I still need to investigate if there is really a reversion here, it's worth noting that you can probably avoid the slow speed by running:
git config filter.annex.process 'git-annex filter-process'
That needs a current daily build of git-annex, the feature will also be in the next release.