After unlocking a file, git status runs the smudge filter. That is unnecessary, and when many files were unlocked, it can take a long time because git smudge clean interface suboptiomal means it runs git-annex once per file.

It should be possible to avoid that, as was done with git drop in 1113caa53efedbe7ab1d98b74010160f20473e8d. I tried making Command.Unlock use restagePointerFile, but that did not help; git update-index does then smudge it during the git annex unlock, which is no faster (but at least doing it then would avoid the surprise of a slow git status or git commit -a). Afterwards, git status then smudged it again, unsure why! --Joey

I wondered if this was still a problem in a v9 repository with filter-process used instead of smudge. It's not really -- after unlocking 1000 files, git status did need to refresh all 1000, but it ran relatively quickly because it was able to use filter-process.

But, those were small files. Large files would make it slower as it pipes their content though. It would be better for Command.Unlock to use restagePointerFile, so whatever price there is is paid during unlocking and not unexpectedly later on.

I tried again making Command.Unlock use restagePointerFile, and this slowed git-annex unlock. But git status did then avoid doing any more smudgeing. It seems that each call to restagePointerFile is running git update-index, so still one git-annex smudge per file, rather than combining several together. In a v8 repo, the same amount of work is done either way. In v9+, this is actually slower than before when the files are small.

restagePointerFile was running git update-index once per file because restagePointerFile uses the git queue, and unlock also queues a git add or something, so the queue isn't able to built up because two dissimilar things are being queued. This seems an unnecessary behavior; it could queue up all the git adds and then run restagePointerFile after them all. Implemented that, and done! --Joey