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-12-28 14:32:29 -04:00
commit 0bc63a0620
5 changed files with 79 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
doc/design/assistant/blog/day_12__freebsd_redux/comment_3_5ab7808595e3b51ca4141d15fdd44743._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="chris"
subject="Thanks"
date="2014-12-25T11:58:55Z"
content="""
Thanks
"""]]

37
doc/forum/is_there_a_way_to_automatically_retry_when_special_remotes_fail__63__.mdwn Normal file
View file

@ -0,0 +1,37 @@
I'm storing hundreds of gigabytes of data on a S3 remote, and often when I try to copy to my remote using this type of command:
git annex copy newdir/* --to my-s3-remote
I'll get a little bit of the way uploading some large file (which is in chunks) and then something like this:
copy newdir/file1.tgz (gpg) (checking my-s3-remote...) (to my-s3-remote...)
3% 2.2MB/s 11h14m
ErrorMisc "<socket: 16>: Data.ByteString.hGetLine: timeout (Operation timed out)"
failed
copy newdir/file2.tgz (checking my-s3-remote...) (to my-s3-remote...)
15% 2.3MB/s 3h40m
ErrorMisc "<socket: 16>: Data.ByteString.hGetLine: resource vanished (Connection reset by peer)"
failed
copy newdir/file3.tgz (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) (checking my-s3-remote...) ok
One common cause of this is if my Internet connection is intermittent. But even when my connection seems steady, it can happen. I'm willing to chalk that up to network problems elsewhere though.
If I keep just hitting "up enter" to re-execute the command each time it fails, eventually everything gets up there.
But this can actually take weeks, because often uploading these big files, I'll let it go overnight, and then wake up every morning and find out with dismay that it has failed again.
My questions:
- Is there a way to make it automatically retry? I am sure that upon any of these errors, an immediate automatic reply would amost assuredly work.
- If not, is there at least a way to make it pick up where it left off? Even though I'm using chunks, it seems to start the file over again.
Thanks.

26
doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_4_cd04cfaf97f200d5e581b83bb8d018b2._comment Normal file
View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkRW96vF6lsjg57muQ4nPnQqJJUAKGKGzw"
nickname="Catalin"
subject="Caveat with 'git checkout synced/master'"
date="2014-12-26T07:43:18Z"
content="""
There's at least one caveat with the 'git checkout synced/master' workaround. When the local assistant next tries to sync with the remote, it will try to push, and the remote will refuse the push into the currently checked out branch:
[2014-12-26 02:40:10 EST] main: Syncing with nyc.nanobit.org_annex
remote: error: refusing to update checked out branch: refs/heads/synced/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To ssh://catalinp@git-annex-nyc.nanobit.org-catalinp_22_annex/~/annex/
! [remote rejected] annex/direct/master -> synced/master (branch is currently checked out)
"""]]

2
doc/tips/publishing_your_files_to_the_public.mdwn
View file

@ -46,7 +46,7 @@ To share all the links in a given folder, for example, you can go to that folder
The same applies to all the filters you can do with git-annex.
For example, let's share links to all the files whose _author_'s name starts with "Mario" and are, in fact, stored at your public-s3 remote.
However, instead of just a list of links we will output a markdown-formatted list of the filenames linked to their S3 files:
However, instead of just a list of links we will output a markdown-formatted list of the filenames linked to their S3 urls:
for filename in (git annex find --metadata "author=Mario*" --and --in public-s3)
echo "* ["$filename"](https://public-annex.s3.amazonaws.com/"(git annex lookupkey $filename)")"

8
doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_2_80d1080bf6e82bd8aaccde9d7c1669c7._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://launchpad.net/~krastanov-stefan"
nickname="krastanov-stefan"
subject="Status of this issue"
date="2014-12-27T15:18:42Z"
content="""
I was unable to find a way to tell git-annex that certain remotes should receive multiple transfers in parallel. Is this implemented yet or on the roadmap? If neither would modifying the webapp to bear this logic without touching git-annex itself be a solution (asking mainly because it can be done with a greasemonkey script)?
"""]]