0151976676
Detected while reading recent CHANGELOG entry but then decided to apply to entire codebase and docs since why not?
39 lines
2.1 KiB
Markdown
39 lines
2.1 KiB
Markdown
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. 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]]
|