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

4 files changed, 58 insertions, 0 deletions

diff --git a/doc/bugs/long_running_assistant_causes_resource_starvation_on_OSX.mdwn b/doc/bugs/long_running_assistant_causes_resource_starvation_on_OSX.mdwn
new file mode 100644
index 000000000..63ccb693b
--- /dev/null
+++ b/doc/bugs/long_running_assistant_causes_resource_starvation_on_OSX.mdwn
@@ -0,0 +1,24 @@
+What steps will reproduce the problem?
+
+leave the assistant running for multiple days
+
+What is the expected output? 
+
+Glorious git-annex enlightenment
+
+What do you see instead?
+
+After ~2-3 days, there are hundreds of zombied git processes and the system is unable to fork new processes. This has occurred on 3 differently hardware configured mac's (macbooks and imacs) all running Mountain Lion 10.8.2 Build 12C3006
+In each case, once the system gets to this point, the only solution is forcing a reboot by holding down the power button as not even kill can spin up it's process.
+
+What version of git-annex are you using?
+
+    git-annex version: 3.20130122
+
+On what operating system?
+
+Mac OSX 10.8.2 Mountain Lion Build 12C3006
+
+Please provide any additional information below.
+
+I'm really not sure what to look for next. Happy to take suggestions.
diff --git a/doc/forum/recovering_from_repo_corruption.mdwn b/doc/forum/recovering_from_repo_corruption.mdwn
new file mode 100644
index 000000000..42df61b78
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption.mdwn
@@ -0,0 +1,11 @@
+In my current annex config, I have 4 computers with "traditional" git annexes as well as an external drive that is a git annex, an rsync'd backup annex, and a glacier archive.  Today, one of the computers got a corrupted git repo. It was complaining that a pack file was invalid. In my attempts to fix it, a commit was logged that deleted every file in the annex. I didn't find this out until I did 'git annex sync' and watched git delete everything, then send all those commits to my other 3 systems and the external drive. *facepalm*
+
+Fortunately, I had one of those other systems in direct mode and I copied everything from the annex as a backup. Now, when I try to re-add files to the annex, I'm running into some errors. These appear to be "collisions" within the annex part of the .git folder:
+
+    %  › git annex add House.netspd 
+    add House.netspd (checksum...) 
+    git-annex: /Users/akraut/Desktop/annex/.git/annex/objects/31/Gw/SHA256E-s167433--41e68ea0adb5a4086a0b7b39d0556b9b86523ffb6b498d58f12f96460da315e9/SHA256E-s167433--41e68ea0adb5a4086a0b7b39d0556b9b86523ffb6b498d58f12f96460da315e9.map.tmp62699: openFile: permission denied (Permission denied)
+    failed
+    git-annex: add: 1 failed
+
+Any ideas on what's going on here? Perhaps how to get things added back in or recovered? It seems all the actual file contents are here, but annex doesn't seem to know they're there anymore.
diff --git a/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment b/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment
new file mode 100644
index 000000000..ab65b42cb
--- /dev/null
+++ b/doc/forum/recovering_from_repo_corruption/comment_1_01fc85037e24fc70e5c5329898cf6781._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://edheil.wordpress.com/"
+ ip="99.54.57.201"
+ subject="comment 1"
+ date="2013-01-26T07:11:35Z"
+ content="""
+speaking strictly from the git point of view, you can create a new commit that reverses an old commit completely.
+
+    git revert <commit>
+
+creates a new commit which does the exact opposite of the commit you specify.  Theoretically it bring everything back to you quick and clean!
+
+
+
+"""]]
diff --git a/doc/todo/wishlist:_addurl_https:.mdwn b/doc/todo/wishlist:_addurl_https:.mdwn
new file mode 100644
index 000000000..bfb1c9283
--- /dev/null
+++ b/doc/todo/wishlist:_addurl_https:.mdwn
@@ -0,0 +1,8 @@
+It would be nice if "git annex addurl" allowed https: urls, rather than just http:.
+To give an example, here is a PDF file:
+
+ https://www.fbo.gov/utils/view?id=59ba4c8aa59101a09827ab7b9a787b05
+
+If you switch the https: to http: it redirects you back to https:.
+
+As more sites provide https: for non-secret traffic, this becomes more of an issue.