git-annex/doc/todo/git_status_smudges_unncessarily_after_unlock.mdwn

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 [[!commit
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]]

[[!tag confirmed]]

> 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.
> 
> That's 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
> unncessary behavior; it could queue up all the git adds and then
> run restagePointerFile after them all.