### Please describe the problem.

While the assistant is synchronizing (to local USB backup disks or remote repositories) I am continually prompted for GPG passphrase when it is most definitely already in the gpg-agent.

### What steps will reproduce the problem?

Set up some remote gcrypt repositores using an existing GPG key, add some files, use the system, you are prompted for the passphrase far more often than the timeout of the passphrase in the agent (every few minutes). The number of times you are prompted also seems to increase linearly with the number of repositories - I am guessing they all exhibit the same need for the passphrase and all request at once, resulting in a string of 10+ pinentry popups.

I am wondering if there is something specific in my gpg setup that git annex isn't expecting. Always encrypt to self? Signing subkeys? Either way, standard tools manage to call gpg to encrypt/decrypt using gpg-agent and not prompting for the passphrase, so git annex should be able to as well.

### What version of git-annex are you using? On what operating system?

Arch Linux, 5.20140831-g62e6ad8 

### Please provide any additional information below.

I have read the various discussions about using -R or -r for the recipients, and I can see in the logs that -r is being used, but there is definitely something not working correctly. At the same time that git annex is making a gpg-agent request that results in a passphrase request, I can encrypt and decrypt whatever files I want manually with no prompting.

[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log

gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Decrypting manifest
gcrypt: Decrypting manifest
gpg: anonymous recipient; trying secret key 7426266D ...
gpg: anonymous recipient; trying secret key 7426266D ...
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 11 Sep 2014 06:21:58 BST using RSA key ID AC305414
gpg: Good signature from "user <XXXXXX>" [ultimate]
gpg:                 aka "[jpeg image of size 2004]" [ultimate]
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 11 Sep 2014 06:21:58 BST using RSA key ID AC305414
gpg: Good signature from "user <XXXXXX>" [ultimate]
gpg:                 aka "[jpeg image of size 2004]" [ultimate]
gcrypt: WARNING:
gcrypt: WARNING: Remote ID has changed!
gcrypt: WARNING: from :id:QydYJR8dPq7y7kMUQDG1
gcrypt: WARNING: to   :id:gU3sc34/rhmta4xfSm3O
gcrypt: WARNING:
gcrypt: Encrypting to:  -r 49AFD42BB9E8CD9D
gcrypt: Requesting manifest signature
gcrypt: Encrypting to:  -r 49AFD42BB9E8CD9D
gcrypt: Requesting manifest signature
gcrypt: Decrypting manifest
gpg: anonymous recipient; trying secret key 7426266D ...
gpg: okay, we are the anonymous recipient.
gpg: Signature made Thu 11 Sep 2014 06:22:58 BST using RSA key ID AC305414
gpg: Good signature from "user <XXXXXXX>" [ultimate]
gpg:                 aka "[jpeg image of size 2004]" [ultimate]
gcrypt: Encrypting to:  -r 49AFD42BB9E8CD9D
gcrypt: Requesting manifest signature
gpg: cancelled by user
gpg: skipped "49AFD42BB9E8CD9D": Operation cancelled
gpg: [stdin]: sign+encrypt failed: Operation cancelled
error: failed to push some refs to 'gcrypt::/autofs/ext/wdpassport0/annexes/user/docs'
[2014-09-11 06:36:18 BST] read: git ["--git-dir=/home/user/docs/.git","--work-tree=/home/user/docs","-c","core.bare=false","push","wdpassport0","master"]
...

# End of transcript or log.
"""]]

The section above I clicked cancel on the pinentry dialog as can be seen. The question is, why was it asking me anyway?

> gpg: anonymous recipient; trying secret key 7426266D ...
> 
> That means that you have git-remote-gcrypt configured to use anonymous
> recipients. This causes gpg to try a bunch of gpg keys until it finds one
> that works, rather than immediately trying the right key. 
> 
> I modified git-remote-gcrypt in July so you can configure
> gcrypt.publish-participants to avoid this problem. 
> 
> There may also be a local confguration problem; I don't know. In any
> case, it's not git-annex responsible, but git-remote-gcrypt. [[done]] --[[Joey]]