One way I've lost data is to git-annex-add it in an untrusted temp clone of a repo, then commit and push the git branch, but forget to git-annex-copy the annexed contents referenced by that branch to a GloballyAvailable, (semi-)trusted remote. Then, when the temp clone is gone, the branch pushed to the repo is referencing permanently dead files. Maybe, git-annex-init could install a pre-push hook to check for this, and abort the push if it happens? Basically, to ensure that whatever data is referenced by pushed branches will actually be at least potentially get-table.
Even if the current repo is not temp/untrusted, when sharing data with someone, you may want to ensure that any annexed files referenced by a pushed branch are actually potentially available.
git-annex-getcontent referenced by any pulled commits. Then can use git-annex like git without needing to remember togit-annex-sync. ?operate on files affected by a commit range could be useful in implementing the hooks.Installing such a pre-push hook by default is certianly going to break existing workflows, so I don't see that happening. It would break my own workflows, unless perhaps the hook only does something when the repository is untrusted.
But I don't see anything preventing you from writing such a hook yourself. It should be easy enough to use
git annex whereisor something like that to determine when you want to blick the push. If you need some additional query facility in git-annex to write it, we can talk about that.git-annex-copythe files to a remote, but forgot togit-annex-syncthe new location information, so a new clone could not access the files. Maybe, a pre-push hook could be installed to print a warning (that can be turned off by a config setting), whenever you push refs to annexed files to a remote that has no (semi-)trusted location information for them? Basically, as a git user you get used to thinking thatgit pushsaves your work, and forgetting that it doesn't withgit-annexcan lead to data loss/inaccessibility.