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

4 files changed, 79 insertions, 0 deletions

diff --git a/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn
new file mode 100644
index 000000000..cb3c7ef81
--- /dev/null
+++ b/doc/bugs/__39__add__39___results_in_max_cpu__44___long_run_and_huge_repo.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+massive repo, max cpu using
+
+    git annex add .
+
+had to interrupt the job as it was processing 1 small file per 5 seconds after about 3h run.
+
+I am running it on the root of a large (currently 1TB) exFAT-based drive used for archiving
+
+The repo grew to 28G.
+
+Is this a regular issue with exFAT? I've done quite a bit of searching. I'll do more.
+
+### What steps will reproduce the problem?
+- install on El Capitan (latest) via homebrew
+- create 1TB exFAT file store
+- follow walk through to setup annex locally and on external
+- add
+
+### What version of git-annex are you using? On what operating system?
+git-annex version: 6.20160126
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser 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 S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+El Capitan 10.11.3
+
+
+### 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)
+I'd love to say I have. You'll hear my shout of joy when I do.
diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment
new file mode 100644
index 000000000..d663f3370
--- /dev/null
+++ b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_4_4bcd571dcd6c1e709e83e519135519b3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="mih"
+ subject="Thanks"
+ date="2016-03-02T19:30:49Z"
+ content="""
+Thanks for investigating this further.
+
+One aspect that may make switching the location of the .git directory into the worktree of the submodule less desirable is this: With the actual .git in ../.git/modules/... one can easily rm -rf the submodule, deinit it, and re-init/update from the (still present) ../.git/modules/... at a later point in time. Especially, when a submodule is a more complicated beast (e.g. with multiple configured remotes) the required steps to regenerate the same setup get more complex.
+"""]]
diff --git a/doc/forum/How_to_shrink_transfer_repo__63__.mdwn b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn
new file mode 100644
index 000000000..8e368087f
--- /dev/null
+++ b/doc/forum/How_to_shrink_transfer_repo__63__.mdwn
@@ -0,0 +1,27 @@
+Hello,
+
+I have two repositories (Asaru and Horus) that are both ```group=client``` and ```wanted=standard```. The other one, Astarte is ```group=transfer``` and ```wanted=standard```. Pretty standard I think.
+
+```
+repository mode: direct
+trusted repositories: 0
+semitrusted repositories: 5
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        58001764-966d-4076-ae99-4ef6de25df39 -- Asaru [here]
+        8165bdf1-907e-4bbe-9c35-22fbf6f8cb00 -- Astarte [astarte]
+        cca0c3c8-593a-4395-936c-1093f0f762e8 -- Horus
+untrusted repositories: 0
+```
+
+I always sync on the two client repos like that ```git annex add . && git annex sync --content```. The transfer repo is growing larger and larger. ```git annex dropunused N``` says, that it ```could only verify the existence of 0 out of 1 necessary copies```.
+
+What is the best way to clean up the transfer repo?
+
+1. Make the two client repos trusted? The three repos have been created manually, not through the assistant. Is that what the assistant does, too?
+2. Try to get the two client repos into touch with each other and try to use ```dropunsed --from=astarte```?
+
+What is the recommended way for that?
+
+Thanks,
+Florian
diff --git a/doc/forum/Undo_git_merge_git-annex.mdwn b/doc/forum/Undo_git_merge_git-annex.mdwn
new file mode 100644
index 000000000..bc299174c
--- /dev/null
+++ b/doc/forum/Undo_git_merge_git-annex.mdwn
@@ -0,0 +1,3 @@
+After accidentally typing git merge git-annex, I am now wondering how to clean up the resulting chaos...
+
+Any tips?