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

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

Browse source
This commit is contained in:
Joey Hess 2014-05-19 13:07:03 -04:00
commit ff6ac90138
14 changed files with 138 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/Auto_update_not_updating_to_newest_version/comment_6_8019fa061d74365ea72e32780d288eb4._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 6"
date="2014-05-19T17:06:30Z"
content="""
See [[git-annex_auto_upgrade_is_redundant]] for analysis of this problem.
"""]]

12
doc/bugs/git_annex_costs_not_working_as_expected_in_the_assistant/comment_3_17e9c2d29ddadcabc30ce884ffe0f853._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 3"
date="2014-05-19T16:44:19Z"
content="""
When the assistant wants to download a file, it queues a transfer from all remotes that are known to have the file, with the lowest cost remotes first. If it fails to get the file from the lowest cost remote, it automatically falls back to the next lowest cost, and so on.
If there's a bug here, I'd suspect strongly it's due to having 2 remotes with the same UUID.
Yes, I think I've found it. Assistant.TransferSlots.genTransfer calls performTransfer, which is passed only the Transfer, not the Remote. So it then looks up a remote with the UUID from the Transfer. To fix this, I will need to adjust the transferkeys command's protocol to include the name of the remote that should be used.
"""]]

10
doc/bugs/git_annex_list__47__whereis_and_uncommited_local_changes/comment_2_7c8d91d78608d717164cb3e825654654._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 2"
date="2014-05-19T17:04:16Z"
content="""
Direct mode and indirect mode behave the same here -- in indirect mode, if you unlock and modify a file, whereis will show the location of the annexed file, not the un-added version. In general all git-annex commands except of course `add` and `status` operate on the files that are staged in the index or committed, not un-staged files in the work tree. This is consistent with git's own behavior.
It is true that in direct mode, whereis will say that a file that has been modified is present locally, even though the modification has changed the only local copy of the file -- so it's not actually present locally. However, I don't think it makes sense to make whereis check if the file is actually still locally present before showing it is. whereis shows location tracking information, which can be out of date for many reasons.
"""]]

12
doc/bugs/remote_gcrypt_based_repos_and_conflicting_uuids/comment_4_7eb33c23223dfc634eb3c9c6621f7f3e._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 4"
date="2014-05-19T16:28:01Z"
content="""
I can reproduce this problem on OSX.
I've only gotten as far as seeing that the gcrypt repository never gets initialized as a git repository. It has a config file, but no objects are ever pushed to it. This is why gcrypt sees no repository there in subsequent runs.
This is a bug in gcrypt, so filed: <https://github.com/blake2-ppc/git-remote-gcrypt/issues/15>
"""]]

8
doc/design/assistant/sshpassword/comment_2_36a811bca209c7ac8a44d64bf8bc5bf3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 2"
date="2014-05-19T15:47:19Z"
content="""
I don't feel comfortable prompting for gpg passphrases in the webapp. See [[gpgkeys]] for thoughts on this.
"""]]

8
doc/forum/2_clients_using_an_encrypted_server_for_syncing_-_possible__63__/comment_8_9baacb14fc5eb449cb13e0b4a4995fb0._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 8"
date="2014-05-19T16:48:09Z"
content="""
4.20130815 is too old. Get a current version.
"""]]

12
doc/forum/Automatically_dropping_files/comment_1_f5fc608f9cb0edf3272b586b62050637._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 1"
date="2014-05-19T15:41:05Z"
content="""
`git annex drop --auto` *does* automatically drop files that are not wanted, according to your preferred content settings.
If your preferred content for a repo is `metadata=tag=done`, then only files tagged \"done\" will be kept in the repository.
Of course, files are only dropped if enough other copies can be verified to exist in other repositories..
"""]]

10
doc/forum/Checkout_only_some_files_with_the_assistant/comment_3_7c026e36e1cdd52053c34638c87d793c._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 3"
date="2014-05-19T15:45:57Z"
content="""
There is not currently any UI to do git-annex get/drop.
There is some recent work on [[tips/file_manager_integration]] which lets you use a file manager and pick files you want and files to drop. Nobody has gotten it working with android file manager yet AFAIK.
"""]]

8
doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_4_af4bc222d1479482bd83952353c97f05._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 4"
date="2014-05-19T15:38:14Z"
content="""
No, box.com cannot decrypt your files, because the git repository is not stored on box.com.
"""]]

12
doc/forum/dot_git_slash_annex_slash_tmp/comment_15_839e29d41de9dcc8f01dfdc585a51d12._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 15"
date="2014-05-19T15:43:52Z"
content="""
Since version 5.20140517, the git-annex assistant will automatically clean up stale tmp files on startup.
If not using the assistant, you can do it yourself..
So far, all the tmp files people have been kind enough to share the details about with me seem to be created by the assistant when it locks a file down. I know this can result in dangling files if the computer is rebooted while the assistant is in the middle of doing that.
"""]]

8
doc/forum/rsync.net:_Too_many_authentication_failures_for___42____42____42____42____42__/comment_4_2cd17d01edeb230197865e6ea0884de0._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 4"
date="2014-05-19T16:46:55Z"
content="""
I suggest you upgrade to yesterday's release. It moves ssh password prompting during repository setup into a field in the webapp, so should avoid this class of problems.
"""]]

10
doc/forum/ssh_key_setup_woes_in_Android/comment_1_f16fbff27a449409699f3dbcf9590622._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 1"
date="2014-05-19T15:50:34Z"
content="""
There have been recent improvements in the assistant's handling of ssh keys. This includes no more prompting for ssh keys in the console, ever. Instead, the ssh remote setup would presumably fail if the ssh key didn't work for some reason.
To debug your problem, you need to use the shell. I would first try running \"git annex get\" or \"git annex copy\" or \"git annex drop\" on a file, and verify that it prompts for the ssh password. Then, take a look at /sdcard/git-annex.home/.ssh/config, and see if you can ssh to the special hostname set up there, from android, and if it asks for a password. If so, ssh -v might be interesting, as it should show it presenting the ssh key to the server.
"""]]

10
doc/todo/integrate_support_for_spideroak_as_archive__47__backup/comment_1_a47ea814f6d7727bbd0eeca6d1fd3219._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 1"
date="2014-05-19T15:05:49Z"
content="""
If spideroak has a CLI tool that can get/put/delete individual files, it should be quite easy to use [[the_external_special_remote|special_remotes/external]] to support it. The demo shell script could be used as a starting place.
I built that so that others can easily write special remotes, and so unless spideroak's CLI is free software, I don't anticipate working on this myself.
"""]]

10
doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_4_e5516689bc128c061dcd66649dc69584._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="216.145.95.162"
subject="comment 4"
date="2014-05-19T16:56:15Z"
content="""
erics, that all makes a lot of sense, except I don't know if there's actually a use case for a git-annex that behaves that way. It doesn't seem to solve the original use case.
I'd be inclinded to instead use the new metadata support. A file could have a tag that indicates it's not strongly wanted, and if git-annex get doesn't have enough space it could seek out and drop such files.
"""]]