avoid starting a download for a local transfer when the remote already has the key

Turns out that recvkey already does this same check. This avoids a transfer
file being created for the download that never happened, which in turn
will avoid the assistant seeing that the download has finished, when no
transfer actually took place.

Remote/Git.hs

@@ -269,12 +269,15 @@ copyToRemote r key file
 		params <- rsyncParams r
 		u <- getUUID
 		-- run copy from perspective of remote
-		liftIO $ onLocal r $ do
-			ensureInitialized
-			download u key file $
-				Annex.Content.saveState True `after`
-					Annex.Content.getViaTmp key
-						(rsyncOrCopyFile params keysrc)
+		liftIO $ onLocal r $ ifM (Annex.Content.inAnnex key)
+			( return False
+			, do
+				ensureInitialized
+				download u key file $
+					Annex.Content.saveState True `after`
+						Annex.Content.getViaTmp key
+							(rsyncOrCopyFile params keysrc)
+			)
 	| Git.repoIsSsh r = commitOnCleanup r $ do
 		keysrc <- inRepo $ gitAnnexLocation key
 		rsyncHelper =<< rsyncParamsRemote r False key keysrc file

doc/design/assistant/syncing.mdwn

@@ -36,10 +36,9 @@ all the other git clones, at both the git level and the key/value level.
   that already has the content) and loop, until the git-annex branches catch
   up and break the cycle.
 
-  Possible solution: C could record a download intent. (Similar to a failed
+  Possible solution: C could record a deferred download. (Similar to a failed
   download, but with an unknown source.) When C next receives a git-annex
-  branch push, it could try to requeue downloads that it has such intents
-  registered for. **done**
+  branch push, it could try to queue deferred downloads. **done**
 
   Note that this solution won't cover use cases the other does. For example,
   connect a USB drive A; B syncs files from it, and then should pass them to C.