summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-05-31 13:58:34 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-05-31 13:58:34 -0400
commit9fdf17c2011560c149bea846f970712846e273a2 (patch)
tree4721a0060c10d25305e76c050890267ad1eb3950
parentaa32a539fc0d29b4f1fddeead9c2477190ce15f5 (diff)
parentb6586c7d7890662ed595be950dd59395fb594f4e (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment10
-rw-r--r--doc/bugs/restart_daemon_required.mdwn20
-rw-r--r--doc/bugs/wishlist:_make_git_annex_reinject_work_in_direct_mode.mdwn18
-rw-r--r--doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment11
-rw-r--r--doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment18
-rw-r--r--doc/todo/wishlist:_Restore_s3_files_moved_to_Glacier.mdwn7
6 files changed, 84 insertions, 0 deletions
diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment
new file mode 100644
index 000000000..a252c5ea9
--- /dev/null
+++ b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_2_fb8c0bebb9aaa75ee7eaf6999b1db49e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="EvanDeaubl"
+ ip="12.130.123.174"
+ subject="comment 2"
+ date="2013-05-31T13:38:43Z"
+ content="""
+I share the concerns about the semi-deprecated status, although it's probably safer than they make it sound in the man page. The git test suite for sparse checkouts uses the same command to find files with skip-worktree set, and there are other tools that use it as well (magit being one example). The git maintainers couldn't remove it, or even fully deprecate it for eventual removal. It's been semi-deprecated for almost 3 years.
+
+I have a patch that fixes `git annex sync` and `git annex get` (it retrieved files marked skip-worktree) and it passes `git annex test`, but I'm going to more rigorously test it out on my particular use case before calling it good. When it is ready, I didn't see instructions on how you would like patches submitted anywhere in the wiki. How would you like to receive it?
+"""]]
diff --git a/doc/bugs/restart_daemon_required.mdwn b/doc/bugs/restart_daemon_required.mdwn
new file mode 100644
index 000000000..c09e893db
--- /dev/null
+++ b/doc/bugs/restart_daemon_required.mdwn
@@ -0,0 +1,20 @@
+Git annex refuses to get/drop files until it's manually relaunched.
+
+I'm trying to setup a basic dropbox like system where a couple of computers sync with a local server I have constantly running ubuntu with ssh.
+
+I think I've setup git annex correctly: when I put files in the repo folder they get uploaded to the bare git repo on the server over ssh automatically and the other computer updates with a broken alias to the file. However the file does not then download from the server despite it being available without a manual restart of the daemon or a git-annex get command from the terminal.
+
+Additionally, files inside archive folders do not get dropped once uploaded to the server without a restart of the daemon.
+
+
+My computers are each setup with the ssh server as a 2nd repository (fullarchive), they are both OSX, and running Version: 4.20130521-g25dba9d according to the webapp. I have also entered my gmail/jabber account on each mac which I believe allows them to communicate indirectly when using the ssh repo.
+
+
+I don't know if this is a setup/misconfiguration error or a bug but I can't see how I've setup the assistant wrong, I did manually change the remote url in the config file, as the assistant was having issues connecting (I'm sshing on 21 for various reasons, although I thought this was supported and I no longer receive errors in the webapp now I've specified my remote.
+
+Should I put the corresponding computers as a repositories of each other? I thought each syncing independently with a centralised git would be a more reliable/simple situation than a potential 3 way sync?
+
+
+I hope this is enough information, I'm usually good at working out issues myself, however this is just frustrating me and the git-annex solution is so nearly perfect if it would work reliably that I can't bring myself to give up on it!
+
+Thanks!
diff --git a/doc/bugs/wishlist:_make_git_annex_reinject_work_in_direct_mode.mdwn b/doc/bugs/wishlist:_make_git_annex_reinject_work_in_direct_mode.mdwn
new file mode 100644
index 000000000..41c8e574b
--- /dev/null
+++ b/doc/bugs/wishlist:_make_git_annex_reinject_work_in_direct_mode.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+`git annex reinject` refuses to work while in direct mode.
+
+When in direct mode git annex reinject could simply perform `rm $symlink; mv $file_copy .; git annex add $file`. I prefer having git annex doing that so I am sure I am not messing up (mistakenly adding new files for instance) and everything is properly managed.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 4.20130516.1
+
+~~~~
+$ lsb_release -a
+No LSB modules are available.
+Distributor ID: Ubuntu
+Description: Ubuntu 12.04.2 LTS
+Release: 12.04
+Codename: precise
+~~~~
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment
new file mode 100644
index 000000000..00fbf6a20
--- /dev/null
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_3_42b80ee51ce25775bf4532f53a8ecfe3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="ka7"
+ ip="2001:7b8:155d:0:222:64ff:fe16:dc52"
+ subject="comment 3"
+ date="2013-05-31T15:45:51Z"
+ content="""
+ah, great.
+I'll try the samba way.
+And i guess my git-annex is too old (using the git-annex version: 3.20120629~bpo60+2 from debian-backports)
+thanks !
+"""]]
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment b/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment
new file mode 100644
index 000000000..3a4d02f32
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_1_c576182f39563ae68767391c4227a177._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnaH44G3QbxBAYyDwy0PbvL0ls60XoaR3Y"
+ nickname="Nigel"
+ subject="AWS credentials"
+ date="2013-05-31T10:23:23Z"
+ content="""
+This looks very valuable - Google are offering a free 5GB up until 2013 June 30th
+
+Sign in here[1] get your credentials here[2] under the section “Interoperable Access” (Source[3])
+
+ # Set up AWS credentials
+ $ export AWS_ACCESS_KEY_ID=\"YOUR-KEY\"
+ $ export AWS_SECRET_ACCESS_KEY=\"YOUR-SECRET\"
+
+1. http://gs-signup-redirect.appspot.com/ -or- https://developers.google.com/storage/docs/signup
+2. https://storage.cloud.google.com/m
+3. http://fog.io/storage/
+"""]]
diff --git a/doc/todo/wishlist:_Restore_s3_files_moved_to_Glacier.mdwn b/doc/todo/wishlist:_Restore_s3_files_moved_to_Glacier.mdwn
new file mode 100644
index 000000000..85fc2785c
--- /dev/null
+++ b/doc/todo/wishlist:_Restore_s3_files_moved_to_Glacier.mdwn
@@ -0,0 +1,7 @@
+I would like to use the automated AWS lifecycle rules to move the git annex files store on S3 to Glacier after a bit of time. Git annex need must support this kind of S3 files explicitly in order for it to work.
+
+This is different from the adding a Glacier remote to git annex because of the reasons explained in <http://aws.typepad.com/aws/2012/11/archive-s3-to-glacier.html>.
+
+Basically, the files moved by AWS from S3 to Glacier are not available under the normal Glacier API. In fact, the moved S3 files are listed as available but under the `GLACIER` storage class and need a RESTORE request before they can be GET like other S3 files. Trying to GET an S3 file that has been moved to Glacier will not restore it from Glacier and will result in an 403 error.
+
+I suppose DELETE needs special care as well.