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

5 files changed, 152 insertions, 0 deletions

diff --git a/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment b/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment
new file mode 100644
index 000000000..c21b67f09
--- /dev/null
+++ b/doc/bare_repositories/comment_7_9e065a2d8aaf7371ab7c0bb4f0c724b0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9"
+ nickname="scottgorlin"
+ avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563"
+ subject="synced/* branches necessary on bare repo?"
+ date="2016-10-18T21:17:40Z"
+ content="""
+Are the synced/* branches necessary for a bare repo?  Since there is no working directory, can't sync operate directly on the top level branches of choice, and avoid 'branch pollution'?  Is it implemented this way just to simplify the code, or ...?
+
+Also wondering if there is a practical difference between a bare repo and an rsync repo (other than storing the metadata, of course) - they both use rsync for transfer, no?  Any speed/overhead/other differences to consider when choosing?
+
+For my use case pertaining to question 2 I am using a local ARM NAS which works with the binary (plus S3 or gdrive remotes etc), but I figure why not spin up a private gitlab repo with metadata and no content since I want an off-site backup of the metadata anyways.  Does a bare repo on a nas add anything here, vs an rsync remote?  Perhaps just rsync is even better to avoid overhead on a tiny/slow NAS?
+"""]]
diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment
new file mode 100644
index 000000000..514c85a23
--- /dev/null
+++ b/doc/bugs/assistant_crashes_in_TransferScanner/comment_1_e626d6fc90a4af8906973121149eef7d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2"
+ nickname="johannes"
+ avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c"
+ subject="comment 1"
+ date="2016-10-19T10:28:13Z"
+ content="""
+I just noticed that I get the same error when executing `git annex sync --content`. Nevertheless, the following commands are running flawlessly:
+
+* `git annex sync`
+* `git annex get --auto`
+* `git annex copy -t origin --auto`.
+"""]]
diff --git a/doc/bugs/commenting_on_patches_fails.mdwn b/doc/bugs/commenting_on_patches_fails.mdwn
new file mode 100644
index 000000000..7b71c0ed7
--- /dev/null
+++ b/doc/bugs/commenting_on_patches_fails.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+I was attempting to comment on this patch:
+
+<https://git-annex.branchable.com/todo/PATCH__58___drop_url_parameters_from_extension.hs/>
+
+but adding the comment fails with:
+
+`Error: failed to create directory /home/b-git-annex/source/doc/todo/PATCH__58___drop_url_parameters_from_extension.hs/: File exists`
+
+(this appears to be repeatable.)  At a guess there's actually a file there for the patch... which is why it can't make a directory.
+
+### What steps will reproduce the problem?
+
+1.  Go to <https://git-annex.branchable.com/todo/PATCH__58___drop_url_parameters_from_extension.hs/>
+
+2.  Log in
+
+3.  Click "Add comment"
+
+4.  Enter comment with subject/body
+
+5.  Try to save the comment
+
+
+### What version of git-annex are you using? On what operating system?
+
+N.A.
+
+
+### Please provide any additional information below.
+
+FTR, the original comment I was trying to make was basically "yes, please add this patch" -- but more verbosely:
+
+"""This would be very useful.  **libsyn** seem to have changed their podcast URLs over the last couple of weeks to *always* add a `?dest_id=...` suffix (and changed the historical URL of every single podcast on any feed on their service, the next time it is rebuilt, which has led to a few large sets of duplicate downloads and a bunch of manual cleanup to avoid large duplicate downloads on the ones I noticed in time).  For now I've been doing manual "git mv" as I notice new ones coming in (a few every week), but I'd really prefer it happened automatically."""
+
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Lots of luck with git-annex.  It's extremely useful as both a distributed content store, and also as a podcatcher.  Thanks for writing it :-)
+
+Ewen
diff --git a/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment b/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment
new file mode 100644
index 000000000..89f01b5f7
--- /dev/null
+++ b/doc/git-annex-undo/comment_4_18ed23e07ffed1cbf63e71fb115b0654._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="git-annex-undo: 3 issues and fix suggestions"
+ date="2016-10-21T09:21:16Z"
+ content="""
+Hello Joey.
+
+Thank you for your answer.  It makes things clearer. I believe the documentation should reflect it.  
+
+## Where the bug (1) is: not defining the level of operation
+
+> git annex undo undoes the last change that was committed to the file.
+
+Ah, *committed*. That's an important information.  It's not at all what I expected from reading the page.
+
+I was expecting tree-level undo, not commit-level undo. I've found the bug: *The documentation for git-annex undo does not define \"undo\" or the level at which it operates.*
+
+### Suggestion (1): define the level of operation
+
+What if the documentation included something like this?
+
+> Here, \"undo\" means: \"undo a commit\", that is \"add a commit in the history that undoes the previous commit\".  
+
+## Case (2) of staged changes
+
+> If the file has staged changes, git annex undo first commits those changes (to avoid losing data) and then undoes that commit.
+
+This sounds strange. 
+
+So, if I call git-annex-undo to undo a commit A, but there are staged changes, git-annex-undo will add a commit B then add another commit C to undo B? 
+
+This will not undo A.
+
+What use case where you thinking of?
+
+### Case of staged changes: suggestion (2)
+
+Perhaps in case when file has staged changes, it would be better to display a warning message, perhaps with a `--commit-staged` option to bypass it.
+
+## Internal rationale: got it
+
+> The reason that git annex undo deleted the files from your working tree is that the previous commit did not have those files in it, and it undid to the state at that commit.
+
+> So, you will never lose the content of a file by running git annex undo. If git annex undo deletes a file, you can always get it back by checking out a previous version of the branch. Or even by running git annex undo a second time, to undo the undo.
+
+Ok I understand the data was not lost.  But this kind of reasoning is only reachable when one knows what git-annex-undo really does.  So, this command is still dangerous to the unsavvy.  Perhaps document that?
+
+## Issue (3): What was actually needed (all this time)
+
+It seems that what I really needed was [[git-annex-unannex]].
+
+### Suggested changes to documentation (3)
+
+Perhaps in case when file has staged changes, it would be better to display a warning message *and* suggest using [[git-annex-unannex]] instead?
+
+> If you are looking for a way to undo changes in the directory tree, consider [[git-annex-unannex]].
+
+## Conclusion
+
+What do you think about the 3 issues and fix suggestions?
+
+Thanks again. `git-annex` has started to become useful here.
+
+"""]]
diff --git a/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment b/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment
new file mode 100644
index 000000000..eba946eaa
--- /dev/null
+++ b/doc/special_remotes/webdav/comment_16_2a11dfc1fd159a6b9a25cde71ffec80b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Marco"
+ avatar="http://cdn.libravatar.org/avatar/8cf5e1484973d4f4e58b00720e0dbb26"
+ subject="1und1 Online Speicher"
+ date="2016-10-19T03:42:42Z"
+ content="""
+1und1 (a german ISP) will give you up to 1 TB of space hooked to your DSL account. The setup is a bit weird, so here a short way through that worked for me.
+
+FIrst you need to create a service account to connect to your online storage. To create this account you need to go to the legacy control center. https://login.1und1.de/xml/config/ConfigMain;jsessionid=expired.TCpfix90a?__reuse=123
+Go to \"Online Speicher\" and activate it. Next go to \"Zugänge > Dienstepasswort\" and ensure that one is set up. It seems that you have to wait some time until the password is useable.
+
+The host you need to use is: https://sd2dav.1und1.de/ instead of the one that is mentioned in the manual.
+
+Now you can set the remote up:
+
+> WEBDAV_USERNAME='...' WEBDAV_PASSWORD='...' git annex initremote one type=webdav url=https://sd2dav.1und1.de/git-annex chunk=100mb encryption=shared
+"""]]