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:
parent
c68f52c6a2
commit
faf84aa5c2
6 changed files with 76 additions and 63 deletions
|
@ -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]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue