From 698a55e1b23d8cda6ea1440775cd11b7f5859d1a Mon Sep 17 00:00:00 2001 From: arand Date: Fri, 27 Dec 2013 17:48:20 +0000 Subject: [PATCH 1/3] --- ...new_remote_despite_not_being_asked_to.mdwn | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to.mdwn diff --git a/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to.mdwn b/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to.mdwn new file mode 100644 index 0000000000..014288d5fb --- /dev/null +++ b/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to.mdwn @@ -0,0 +1,44 @@ +### Please describe the problem. +When adding a new remote which is not accessible (hence still unsynced) git annex tries to connect to it at each remote operation, even if a specific other remote is given for the command. + +### What steps will reproduce the problem? +
+git init 1
+
+cd 1
+git annex init
+touch file
+git annex add file
+git commit -m"a file"
+
+git clone . ../2
+
+git remote add 2 ../2
+git annex sync 2
+
+At this point annex syncs with remote "2" and nothing else + +But if adding a (currently) unaccessible remote +
+git remote add bad nobody@offline.local:nothing
+git annex sync 2
+
+gives +
+ssh: Could not resolve hostname offline.local: Name or service not known
+ssh: Could not resolve hostname offline.local: Name or service not known
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+commit  ok
+pull 2 
+ok
+push 2 
+Everything up-to-date
+ok
+
+so annex tries to sync with the "bad" remote, even though the command tells it to only sync from "2". I would expect it to only sync with remote "2" in this case. +### What version of git-annex are you using? On what operating system? +git-annex version: 5.20131221 +Debian Sid From adfb5561303ada79f99dd35eff9a0baa143fc2b4 Mon Sep 17 00:00:00 2001 From: Greg Grossmeier Date: Fri, 27 Dec 2013 10:00:52 -0800 Subject: [PATCH 2/3] more debugging info --- ...f_missing_git-upload_and_receive_pack.mdwn | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/doc/bugs/unable_to_sync_complains_of_missing_git-upload_and_receive_pack.mdwn b/doc/bugs/unable_to_sync_complains_of_missing_git-upload_and_receive_pack.mdwn index fb642ece37..ed8904db46 100644 --- a/doc/bugs/unable_to_sync_complains_of_missing_git-upload_and_receive_pack.mdwn +++ b/doc/bugs/unable_to_sync_complains_of_missing_git-upload_and_receive_pack.mdwn @@ -163,3 +163,40 @@ git lib git-annex libdirs """]] + + + + +### After some debugging with Joey... +12:24 < joeyh> git does not use annex-ssh-options +12:24 < joeyh> the way the assistant sets this up is it makes up a new hostname, and in .ssh/config, makes that hostname use the real domain name, and the key +12:25 < joeyh> there's clearly a bug here.. the assistant only does that when there is no passwordless ssh key already set up. But in this wacky way of installing git and git-annex on a server, it needs to always do it +12:26 < joeyh> probably the assistant should probe if ssh server git-receive-pack works, and if not, always set up its special config +12:26 < joeyh> alternatively, the standalone tarball could have an actual installation step, rather than just being unpacked + +Based on that I added (on the amd64/rose machine): +[[!format sh """ +greg@rose:~/.ssh$ cat config +Host synology + HostName yep.org #obviously redacted + IdentityFile /home/greg/.ssh/annex.rose_rsa + +$ git remote show -n synology +* remote synology + Fetch URL: greg@synology:/volume1/photo/ + Push URL: greg@synology:/volume1/photo/ + HEAD branch: (not queried) + Local ref configured for 'git push' (status not queried): + (matching) pushes to (matching) +"""]] + +Now, to do a simple test with git: + +[[!format sh """ +$ git remote show synology +git-annex-shell: git-shell failed +fatal: Could not read from remote repository. + +Please make sure you have the correct access rights +and the repository exists. +"""]] From 9ddfc6cfaeb294fdb2d26aa1a68583cdeb370992 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Fri, 27 Dec 2013 18:03:14 +0000 Subject: [PATCH 3/3] Added a comment --- ...comment_1_dcd52b57192e83fe365f21dc12461008._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to/comment_1_dcd52b57192e83fe365f21dc12461008._comment diff --git a/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to/comment_1_dcd52b57192e83fe365f21dc12461008._comment b/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to/comment_1_dcd52b57192e83fe365f21dc12461008._comment new file mode 100644 index 0000000000..57b70b47c7 --- /dev/null +++ b/doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to/comment_1_dcd52b57192e83fe365f21dc12461008._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.227" + subject="comment 1" + date="2013-12-27T18:03:11Z" + content=""" +git-annex needs to know the uuid of a remote in order to operate. So at startup, if there is a remote that does not have an annex.uuid set, nearly any git-annex command will try to connect the the remote and query it for its uuid. + +To prevent this being done for a remote, `git config remote.bad.annex-ignore true` +"""]]