bugfix: drop --from an unavailable remote no longer updates the location log, incorrectly, to say the remote does not have the key.

The comments correctly noted that the remote could drop the key and
yet False be returned due to some problem that occurred afterwards.
For example, if it's a network remote, it could drop the key just
as the network goes down, and so things timeout and a nonzero exit
from ssh is propigated through and False returned.

However... Most of the time, this scenario will not have happened.
False will mean the remote was not available or could not drop the key
at all.

So, instead of assuming the worst, just trust the status we have.

If we get it wrong, and the scenario above happened, our location
log will think the remote has the key. But the remote's location
log (assuming it has one) will know it dropped it, and the next sync
will regain consistency.

For a special remote, with no location log, our location log will be wrong,
but this is no different than the situation where someone else dropped
the key from the remote and we've not synced with them. The standard
paranoia about not trusting the location log to be the last word about
whether a remote has a key will save us from these situations. Ie,
if we try to drop the file, we'll actively check the remote,
and determine the inconsistency then.

1 files changed, 2 insertions, 0 deletions

diff --git a/debian/changelog b/debian/changelog
index 75299cf39..31cc06000 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -40,6 +40,8 @@ git-annex (4.20130228) UNRELEASED; urgency=low
     that caused regular browsers to stall when they reuse a connection
     after leaving it idle for 30 seconds.
     (See https://github.com/yesodweb/wai/issues/146)
+  * bugfix: drop --from an unavailable remote no longer updates the location
+    log, incorrectly, to say the remote does not have the key.
 
  -- Joey Hess <joeyh@debian.org>  Wed, 27 Feb 2013 23:20:40 -0400