mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2013-12-27 14:07:48 -04:00
commit eb79670541
3 changed files with 91 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to.mdwn Normal file
View file

@ -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?
<pre>
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
</pre>
At this point annex syncs with remote "2" and nothing else
But if adding a (currently) unaccessible remote
<pre>
git remote add bad nobody@offline.local:nothing
git annex sync 2
</pre>
gives
<pre>
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
</pre>
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

10
doc/bugs/sync_command_tries_to_connect_new_remote_despite_not_being_asked_to/comment_1_dcd52b57192e83fe365f21dc12461008._comment Normal file
View file

@ -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`
"""]]

37
doc/bugs/unable_to_sync_complains_of_missing_git-upload_and_receive_pack.mdwn
View file

@ -163,3 +163,40 @@ git lib
git-annex libdirs 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.
"""]]