faf84aa5c2
Implemented by making Git.Queue have a FlushAction, which can accumulate along with another action on files, and runs only once the other action has run. This lets git-annex unlock queue up git update-index actions, without conflicting with the restagePointerFiles FlushActions. In a repository with filter-process enabled, git-annex unlock will often not take any more time than before, though it may when the files are large. Either way, it should always slow down less than git-annex status speeds up. When filter-process is not enabled, git-annex unlock will slow down as much as git status speeds up. Sponsored-by: Jochen Bartl on Patreon
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
|
|
> unncessary behavior; it could queue up all the git adds and then
|
|
> run restagePointerFile after them all. Implemented that, and [[done]]! --[[Joey]]
|