work around strange auto-init bug
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:
parent
9f94d2894e
commit
b3c4579c79
9 changed files with 33 additions and 20 deletions
|
@ -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]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue