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

8 files changed, 176 insertions, 0 deletions

diff --git a/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn b/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn
new file mode 100644
index 000000000..79df9e0f1
--- /dev/null
+++ b/doc/bugs/Can__39__t_use_adjusted_branch_in_v6__44___if_submodule_already_is_using_this_feature.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+If a v6 submodule is using an adjusted branch, `git annex adjust --unlock` fails in its superproject.
+
+### What steps will reproduce the problem?
+[[!format sh """
+#!/bin/bash
+
+set -ex
+d=$(mktemp -d)
+echo "directory: $d"
+cd $d
+git init
+git annex init --version=6
+echo whatever > file
+git annex add file
+git commit -m "file added"
+mkdir sub
+cd sub
+git init
+git annex init --version=6
+echo something > subfile
+git annex add subfile
+git commit -m "subfile added."
+cd ..
+git submodule add ./sub sub
+git commit -m "submodule added"
+cd sub
+git annex adjust --unlock
+cd ..
+git annex adjust --unlock
+
+"""]]
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+% git annex version
+git-annex version: 6.20170209+gitg16be7b5cc-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: unknown
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+# End of transcript or log.
+"""]]
+
+### 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)
+
+
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn b/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn
new file mode 100644
index 000000000..d26cf3f8c
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+After once embedding credentials into a S3 remote, there’s no way to un-embed them.
+
+### What steps will reproduce the problem?
+
+1. Add a S3 remote with `embedcreds=yes`.
+1. Try to set `embedcreds=no`.
+1. `git annex sync` here, and in some other clone.
+1. Check `git annex info my-s3-remote` for the other clone. Credentials are still embedded.
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101 on NixOS 16.09 (stable).
+
+### Please provide any additional information below.
+
+[[!format sh """
+% g annex info test2 | grep '^creds'
+creds: embedded in git repository (gpg encrypted)
+
+% g annex enableremote test2 embedcreds=no
+enableremote test2 (encryption update) (to gpg keys: 134164FA6FAFE075) ok
+(recording state in git...)
+
+% g annex info test2 | grep '^creds'
+creds: embedded in git repository (gpg encrypted)
+
+%
+"""]]
+
+### 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)
+
+Yes, it’s awesome! Thank you!
diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn
new file mode 100644
index 000000000..eafd22e0b
--- /dev/null
+++ b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+If a submodule is in direct mode, `git annex status` fails.
+Apparently the recursive inspection of submodules is done by an internal call to `git status`, which then misses a working tree in the submodule.
+### What steps will reproduce the problem?
+[[!format sh """
+#!/bin/bash
+
+set -ex
+d=$(mktemp -d)
+echo "directory: $d"
+cd $d
+git init
+git annex init
+echo whatever > file
+git annex add file
+git commit -m "file added"
+mkdir sub
+cd sub
+git init
+git annex init
+echo something > subfile
+git annex add subfile
+git commit -m "subfile added."
+cd ..
+git submodule add ./sub sub
+git commit -m "submodule added"
+cd sub
+git annex direct
+cd ..
+git annex status
+"""]]
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+% git annex version
+git-annex version: 6.20170209+gitg16be7b5cc-1~ndall+1
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: unknown
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### 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)
+
+Yes! I think it's a great piece of software!
diff --git a/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn
new file mode 100644
index 000000000..2c70e371a
--- /dev/null
+++ b/doc/forum/Joey__44___when_would_you_guess_v6_to_be_ready__63__.mdwn
@@ -0,0 +1,3 @@
+A question for Joey: What's the expected schedule for v6 repos becoming solid enough to make them the default? Is it next on the priority list or are you still waiting for some git patches to propagate through or something like that?
+
+I'm asking because I make extensive use of v5 direct mode repos. They sometimes give me a bit of trouble in ways which I hope indirect, unlocked, thin v6 repos could fix. However, I don't want to switch to v6 as long as Joey considers it too experimental/unfinished to be made the default repo format. So I'm trying to decide whether I should put in the effort to investigate the issues I'm having (which are annoying but not catastrophic), or just wait until v6 is ready for prime time.
diff --git a/doc/forum/git_annex_repairs_since_thursday.mdwn b/doc/forum/git_annex_repairs_since_thursday.mdwn
new file mode 100644
index 000000000..c1763b1f9
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday.mdwn
@@ -0,0 +1,5 @@
+I have not tried to get git annex to work in a bit. My troubles of recovering this annex repo have been documented [here](http://git-annex.branchable.com/forum/git_annex_wants_to_repair_every_time_it__39__s_running/), [here](http://git-annex.branchable.com/forum/how_to_disaster_recovery/) and [here](http://git-annex.branchable.com/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/). On Thurs day I thought I give it another try. Since Thursday it tries to repair two out of three repos: my local repo on my laptop and my repo on an external harddrive I have. The b2 special remote repo appears to be fine, or not checked, I'm not sure.
+
+What can I do, to get it working again?
+
+P.S.: In my mind this setup should work like this: I want to move contents from my laptop to the external hdd and to b2 so that there are two copies at all times. I want to use git annex so that I don't need to carry all that stuff around with me anymore, because space on my ssd is sparse.
diff --git a/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment b/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment
new file mode 100644
index 000000000..89fa07cc7
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday/comment_1_38b4563db47ce9bdc52eab5506de20f8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 1"
+ date="2017-02-19T15:27:08Z"
+ content="""
+It's now Sunday and I stopped all three running git-annex processes on my system, after git used about 80% of my cpu, the daemon.log showing nothing and git annex info -F not responding.
+"""]]
diff --git a/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment b/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment
new file mode 100644
index 000000000..726227c43
--- /dev/null
+++ b/doc/forum/git_annex_repairs_since_thursday/comment_2_b072ad2864e1caa7459d17d3426c8eee._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="openmedi"
+ avatar="http://cdn.libravatar.org/avatar/563ffaff3b492c579bd8f094472e4506"
+ subject="comment 2"
+ date="2017-02-19T22:03:26Z"
+ content="""
+I am now trying to just start again. I have initiated a completely new repo to which I'm now adding files from the old repo manually or rather I have already done so, set up two remotes (flash drive and external hdd) and have now a repo which hold at least those files which were unproblematic to move over.
+
+I try now to recover any lost files and at the same time try to get rid of the repo on my laptop. Therefore I initiated on my external drive for disk space reasons a cloned copy of my local repo to which I'm now `get`ing  everything via `git annex get -A`. After this is done, I'll move the missing files, if there are any, over to the new repo by hand and will drop all files on my laptop's repo (to make sure that the new external hdd repo includes everything) and then delete any and all repos and special remotes.
+
+A fresh start seems to be the best way to go, since the old repo just couldn't be repaired by the assistant or me for that matter - or so it seemed.
+"""]]
diff --git a/doc/users/ben.mdwn b/doc/users/ben.mdwn
new file mode 100644
index 000000000..1e6295cbd
--- /dev/null
+++ b/doc/users/ben.mdwn
@@ -0,0 +1 @@
+No idea yet