After running git-annex get in an unlocked (adjusted) v8 repo with git-annex 8.20200330, I see:
git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh
And indeed, some of the files I just got show as new, others as modified.
Where can I find more information on what happened here?
How can I run the update-index command safely without listing hundreds of files? Can I just run it over the directories those files were copied to?
Would you consider adding an option to run the update-index automatically where needed?
UPDATE: I just notice that the assistant apparently deleted some files from the git repository. When I check the file path with git log <file> I see the initial addition (locked, on a different machine, not adjusted) and then a deletion of the symlink on the machine where I executed git annex get. This is rather terrifying!
The file is still in the filesystem. The last commit to the annex happened over 30m ago, the last log in daemon.log over 20m ago. The assistant will probably not add these files back? But even if it would. It is dangerous that a simple git annex get leads to delete commits.
git-annex does try to run git update-index, but it will fail if some other use of git has the index locked, resulting in that message.
As for the assistant committing deletions, one way that could happen is if the assistant observes a brief window where the pointer file has been deleted and the file with the content is not yet in place. But then the assistant should later notice that the file has come back, and make a new commit adding it back. If the assistant did not make that later commit, something else is going on.