Russ Allbery wrote: > I have an annex that's fully synced with its remote. git annex get > returns nothing, successfully, on both ends. But if I run > git annex sync --content (which I would also expect to return nothing > successfully), I get a stream of errors like the following: > > copy Arnold Weinstein/Understanding Literature and Life/01 - Why Literature > -- Civilization and Its Discontents.mp3 (to origin...) git-annex-shell: key > is already present in annex
Hmm, this could in theory happen when using `git annex copy --to`, in a couple of situations where the git-annex branch's location tracking info is wrong. There are a variety of situations where the git-annex branch can be out of date WRT what's present in the remote repository. But, copy --to does an active check to see if the remote has content before trying to send it. This narrows any cases where this could happen down to essentially races (eg, some other repo copies the same file to the remote just before). sync --content does not currently do that check, so it's much more likely to see that happen (as is git annex copy --fast --to). This was an oversight, it can be fixed and the code made shorter too by having sync --content reuse the code used for git annex copy. Also has the benefit of updating the local git-annex branch when the check detects an inconsistency. > rsync: connection unexpectedly closed (0 bytes received so far) [sender] > rsync error: error in rsync protocol data stream (code 12) at io.c(226) > [sender=3.1.0] > rsync failed -- run git annex again to resume file transfer > failed It would be nice to lose all this verbosity about a non-error condition. It mostly happens because git-annex runs rsync to transfer the file, with git-annex-shell on the other end. So it can't propigate an error without making rsync output that, and the local git-annex has no way of knowing why rsync failed. -- see shy jo
signature.asc
Description: Digital signature
