Avoid git status taking a long time after git-annex unlock of many files.

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
This commit is contained in:
Joey Hess 2022-02-18 15:06:40 -04:00
parent c68f52c6a2
commit faf84aa5c2
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 76 additions and 63 deletions

View file

@ -27,10 +27,13 @@ commit -a`). Afterwards, `git status` then smudged it again, unsure why!
> 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.
> 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.
>
> That's because restagePointerFile uses the git queue, and unlock
> 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.
> run restagePointerFile after them all. Implemented that, and [[done]]! --[[Joey]]