mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

work around strange auto-init bug

Browse source 
git-annex get when run as the first git-annex command in a new repo did not
populate unlocked files. (Reversion in version 8.20210621)

I am not entirely happy with this, because I don't understand how
428c91606b caused the problem in the first
place, and I don't fully understand how skipping calling scanAnnexedFiles
during autoinit avoids the problem.

Kept the explicit call to scanAnnexedFiles during git-annex init,
so that when reconcileStaged is expensive, it can be made to run then,
rather than at some later point when the information is needed.

Sponsored-by: Brock Spratlen on Patreon
This commit is contained in:
Joey Hess 2021-07-30 18:36:03 -04:00
parent 9f94d2894e
commit b3c4579c79
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
9 changed files with 33 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/initial_get_of_unlocked_file_fails_to_populate_pointer.mdwn
View file

@ -6,4 +6,12 @@ If any other git-annex command is run before the get, it avoids the
problem. So the problem has to do with autoinit followed by reading
associated files from the keys db.
Besected to [[!commit 428c91606b434512d1986622e751c795edf4df44]] --[[Joey]]
Bisected to [[!commit 428c91606b434512d1986622e751c795edf4df44]] --[[Joey]]
It seems that reconcileStaged is populating the
associated files, but later when they're queried, the query returns an
empty list. So something to do with database write caching.
Somehow, not having init call `scanAnnexedFiles` makes this bug go away.
> [[fixed|done]] --[[Joey]]