sync --content: Fix bug that caused transfers of files to be made to a git remote that does not have a UUID. This particularly impacted clones from gcrypt repositories.

Added guard in Annex.Transfer to prevent this problem at a deeper level.

I'm unhappy ith NoUUID, but having Maybe UUID instead wouldn't help either
if nothing checked that there was a UUID. Since there legitimately need to
be Remotes that do not have a UUID, I can't see a way to fix it at the type
level, short making there be two separate types of Remotes.

Annex/Transfer.hs

@@ -46,10 +46,17 @@ noObserver :: TransferObserver
 noObserver _ _ _ = noop
 
 upload :: Observable v => UUID -> Key -> AssociatedFile -> RetryDecider -> TransferObserver -> (MeterUpdate -> Annex v) -> NotifyWitness -> Annex v
-upload u key f d o a _witness = runTransfer (Transfer Upload u key) f d o a
+upload u key f d o a _witness = guardHaveUUID u $ 
+	runTransfer (Transfer Upload u key) f d o a
 
 download :: Observable v => UUID -> Key -> AssociatedFile -> RetryDecider -> TransferObserver -> (MeterUpdate -> Annex v) -> NotifyWitness -> Annex v
-download u key f d o a _witness = runTransfer (Transfer Download u key) f d o a
+download u key f d o a _witness = guardHaveUUID u $
+	runTransfer (Transfer Download u key) f d o a
+
+guardHaveUUID :: Observable v => UUID -> Annex v -> Annex v
+guardHaveUUID u a
+	| u == NoUUID = return observeFailure
+	| otherwise = a
 
 {- Runs a transfer action. Creates and locks the lock file while the
  - action is running, and stores info in the transfer information

CHANGELOG

@@ -5,6 +5,9 @@ git-annex (6.20160528) UNRELEASED; urgency=medium
     union merging and performing transitions.
   * Remove Makefile from cabal tarball; man page building is now handled by
     a small haskell program.
+  * sync --content: Fix bug that caused transfers of files to be made 
+    to a git remote that does not have a UUID. This particularly impacted
+    clones from gcrypt repositories.
 
  -- Joey Hess <id@joeyh.name>  Fri, 27 May 2016 13:12:48 -0400
 

Command/Sync.hs

@@ -106,7 +106,8 @@ seek o = allowConcurrentOutput $ do
 
 	remotes <- syncRemotes (syncWith o)
 	let gitremotes = filter Remote.gitSyncableRemote remotes
-	let dataremotes = filter (not . remoteAnnexIgnore . Remote.gitconfig) remotes
+	let dataremotes = filter (\r -> Remote.uuid r /= NoUUID) $ 
+		filter (not . remoteAnnexIgnore . Remote.gitconfig) remotes
 
 	-- Syncing involves many actions, any of which can independently
 	-- fail, without preventing the others from running.

doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn

@@ -71,3 +71,5 @@ The remote server that use ssh is Debian Jessie, without git-annex installed (I
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes, everything works very nicely except this issue.
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_2_d4e46b73fa82ba84b123bc4f2d372ea9._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-06-02T17:32:24Z"
+ content="""
+The bug is limited to `git annex sync --content` because it
+didn't check if the git remote had no git-annex UUID before
+sending files to it. Commands like `git annex copy` always check that the
+remote has a UUID.
+
+I've made `git annex sync --content` also check for a UUID. So, it won't
+send any file contents to the origin remote in this configuration. I don't
+think it makes sense to have git-annex auto-promote the origin remote to a
+gcrypt special remote; you can just enableremote the special remote to make
+git-annex send the files to it, properly encrypted.
+
+When this bug occurs, git-annex actually doesn't remember that it's sent
+the un-encrypted files to the remote. I suggest that you just delete all
+files in the remote's annex/ directory of the gcrypt repository
+whose names do not start with "GPGHMACSHA1", in order to clean up from this
+bug.
+
+----
+
+The deeper problem is git-annex is able to transfer objects to a remote
+that does not have a UUID at all. I've put in a guard at a deeper level to
+prevent this whole class of problems.
+"""]]