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

6 files changed, 86 insertions, 0 deletions

diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment
new file mode 100644
index 000000000..06f90b081
--- /dev/null
+++ b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
+ nickname="timothyhobbs"
+ subject="comment 2"
+ date="2016-04-04T21:21:56Z"
+ content="""
+When I launch the annex assistant web app, it should do nothing to the repository, because I have not told it to do anything. I have only tried to open up what, to me, the naive user, is some gui app. I know of no other gui app that initializes an operation simple by way of being opened. Does synaptic update your system when you click \"Applications Menu -> Settings -> Synaptic package manager\"?
+
+You say that I have to shoot myself in the foot repeatedly and manually to do it, but that simply isn't true. There is nothing wrong with initializing a git repo in ~/ in order to, say, track changes to dot files. There shouldn't be anything wrong with running \"git annex init\" in that git repo, to, for example, track some binaries in ~/bin. Afterall, I didn't \"git annex add .\" I was trying to use git annex to track specific and manually specified files.
+
+I actually ended up opening the assistant, from the Applications Menu, for a reason entirely unrelated to the git annex repo that happened to be located in ~/. So I hope you can imagine my shock, when by simply opening what I thought was going to be a gui that I could use to manage some entirely unrelated repositories, I actually ended up running a command on the repository in ~/.
+"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment
new file mode 100644
index 000000000..386ea5e2d
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
+ nickname="timothyhobbs"
+ subject="comment 22"
+ date="2016-04-05T09:19:59Z"
+ content="""
+You are right, that the merging picture doesn't work out if you have a \"single entity\" spread across multiple files. Whether that be a version control system like git or mercurial, or a package unpacked by a package manager. I do not plan on doing any merging. I want to esencially store the file trees of Docker images in git annex. What does it even mean to merge two Docker images? Would you expect that when merging an image based on a debian base image which has git installed, with one that has vim installed, that you would get an image with both git and vim? That would be cool, obviously, but I don't think that it is going to happen, and I don't need it to. OSTree doesn't have merging. You cannot merge two Docker images which happen to be based on the same base image...
+
+So while it is true, that tracking multifile entities in git-annex breaks merging, that doesn't make it silly.
+"""]]
diff --git a/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn b/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn
new file mode 100644
index 000000000..28c30bbd2
--- /dev/null
+++ b/doc/bugs/Cannot_add_gcrypt_remote_in_webapp__58___gcrypt_backend.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+I have a repository that is encrypted using GPG. It is supposed to sync a folder between two laptops. (Note: this is a DIFFERENT repository than the one in my other bug report https://git-annex.branchable.com/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant/ but the setup is the same)
+
+I set everything up on laptop1. This time, I decided to wait for the syncing to finish, between laptop1 and laptop2 in order to prevent corruption. After laptop1 had finished syncing, I went to laptop2 and setup the repository.
+
+- I created a local repository on laptop2.
+- I told the webapp to combine repositories.
+
+Then I got
+
+"
+Internal Server Error
+Cannot find configuration for the gcrypt remote at ssh://denisa@vps.ip/backup/annex/denisa/Studium
+"
diff --git a/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn
new file mode 100644
index 000000000..9a8eed58f
--- /dev/null
+++ b/doc/bugs/Packfile_does_not_match_digest__58___gcrypt_with_assistant.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+I tried to sync a folder between two laptops, using the webapp and GPG encryption. I started by seting up the repository on laptop1, and then, while all the files were uploading, I went over to laptop2 and set things up there as well.
+
+At first, everything looked fine, laptop1 was uploading and laptop2 was downloading. Then, laptop2 reported "Failed to sync with VPS, and the log file showed a gcrypt error: "Packfile long-hash does not match digest!"
+
+### What version of git-annex are you using? On what operating system?
+
+
+
+Laptop1 is running wheezy with git annex version 6.20160307+gitgb095561-1~ndall+1 from neurodebian.
+
+VPS is running wheezy
+
+Laptop2 is runing jessie with git annex version 6.20160307+gitgb095561-1~ndall+1 from neurodebian.
+
+### Please provide any additional information below.
+
+http://denisa.hobbs.cz/laptop1.daemon.log
+http://denisa.hobbs.cz/laptop2.daemon.log
+
+### Have you had any luck using git-annex before?
+
+If I could get this syncing to work, then that would be great! I don't want to use unison, because that wouldn't be encrypted... So this would be wonderful.
+
diff --git a/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__/comment_3_3eb4c2290e560451e7341b85b58212b0._comment b/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
new file mode 100644
index 000000000..a2ac70fae
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 3"
+ date="2016-04-05T17:24:06Z"
+ content="""
+You're right, after the initial run there is no smudge filter overhead. I ran htop in tree view and got this result:
+
+    git-annex-assistant (55-60%)
+      |--> git-annex-assistant (six instances, a couple of those with load 20-40%, the others idling at 0%)
+      |--> git ls-files (mostly idle)
+      |--> git check-attr (mostly idle)
+      |--> git check-ignore (mostly idle)
+      |--> git cat-file (stuck at 40-60%)
+"""]]
diff --git a/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment b/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment
new file mode 100644
index 000000000..b10bf1822
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_24_3340d3c34f2ec197f9010d97da8eb7af._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="szrc"
+ subject="comment 24"
+ date="2016-04-05T01:18:53Z"
+ content="""
+Thanks for the response, Joey. It seems to me that many/most operations for which credentials are needed will require a gpg prompt anyway, but I can see why it might be too expensive in some cases.
+
+Anyway, if you ever saw fit to add the option to disable or limit local caching, I would definitely use it -- and I'm guessing I'm not the only one who would prefer not to store credentials in plaintext.
+
+Thanks for all of your great work on git-annex.
+"""]]