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

16 files changed, 238 insertions, 0 deletions

diff --git a/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
new file mode 100644
index 000000000..730df1d27
--- /dev/null
+++ b/doc/bugs/Visual_glitch_while_xmpp_pairing.mdwn
@@ -0,0 +1,12 @@
+### Please describe the problem.
+When pairing with xmpp buddys, the well does not expand to fit the whole buddy list
+
+### What steps will reproduce the problem?
+Go to the pairing menu
+
+### What version of git-annex are you using? On what operating system?
+ 5.20140717 from the homebrew bottle
+
+### Please provide any additional information below.
+
+![image of bug](http://i.imgur.com/fZe1ERD.png)
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment
new file mode 100644
index 000000000..42537f9f4
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_5_0d7a4f740180dff7c0853062e4913804._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Relying on path is not best practice in a Windows environment"
+ date="2014-08-25T16:16:33Z"
+ content="""
+Unlike under POSIX environments
+generally applications under windows don't add themselves to path,
+or to a directory already in path.
+
+Generally applications announce their location using the registry.
+Under either HKEY_LOCAL_MACHINE\SOFTWARE,
+or in case of software installed for one particular user only
+under HKEY_CURRENT_USER\SOFTWARE.
+
+Git however AFAIK does not.
+Most likely the best thing to do is to prompt the user when installing git-annex
+where git is, and store this variable.
+
+Note that in both my installs I installed git-annex into the git directory,
+and the git-annex webapp still couldn't find it. 
+"""]]
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment
new file mode 100644
index 000000000..4cbf0ea58
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_6_748aa921afee3d7e4667dee50e70a558._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBmv0HhwTFxkpxlf8ifTlMOHnIwHCHTYs"
+ nickname="y"
+ subject="path on windows"
+ date="2014-08-26T12:18:39Z"
+ content="""
+To add to my comment I also installed git-annex in the same directory as the msys git distrib in both cases.
+"""]]
diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn
new file mode 100644
index 000000000..3933fcbba
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up.mdwn
@@ -0,0 +1,28 @@
+~~~~
+$ git annex version
+git-annex version: 5.20140818-g10bf03a
+~~~~
+
+When repository was initially created, it used "old" hashing from http://git-annex.branchable.com/internals/hashing/ . After some operations, annex was upgraded to "new" format. However, symlinks are still in "old" format and dangling. "git annex fsck", "git annex repair", "git annex pre-commit" - none helps.
+
+~~~~
+$ ls -l pics
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 IMG_3776.JPG -> ../.git/annex/objects/KM/j6/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 renamed2.jpg -> ../.git/annex/objects/7F/z3/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+lrwxrwxrwx 1 pfalcon pfalcon 199 Jan 22  2012 renamed.jpg -> ../.git/annex/objects/W1/vK/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+
+$ find .git/annex/objects/
+.git/annex/objects/
+.git/annex/objects/219
+.git/annex/objects/219/741
+.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+.git/annex/objects/219/741/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG/SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+.git/annex/objects/7a6
+.git/annex/objects/7a6/632
+.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+.git/annex/objects/7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+.git/annex/objects/df3
+.git/annex/objects/df3/9a8
+.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+.git/annex/objects/df3/9a8/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG/SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+~~~~
diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment
new file mode 100644
index 000000000..8ca81d325
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_1_5ed3f7b21b007e269f5846cb2d805493._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 1"
+ date="2014-08-24T20:27:08Z"
+ content="""
+Aha, so local repo is created with old hash format. But when you add remote (special rsync remote in my case), and copy --to it, it uses new hashes:
+
+~~~~
+copy 20120122 Routing doorbell/IMG_3776.JPG (checking nas-rsync...) (to nas-rsync...) 
+sending incremental file list
+7a6/
+7a6/632/
+7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/
+7a6/632/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG/SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+~~~~
+
+This explains this nonsense:
+
+~~~~
+$ git annex unused --from=nas-rsync
+unused nas-rsync (checking for unused data...) (checking master...) 
+  Some annexed data on nas-rsync is not used by any files:
+    NUMBER  KEY
+    1       SHA256E-s585398--005fe0534d6cc17a3536c1817b091d00249834c338f289ec6569e9f262889251.JPG
+    2       SHA256E-s688630--5bc2e8beb7a57f6fbcd7d9321cd5283f04448ea475099dac07ae38f002208040.JPG
+    3       SHA256E-s676047--3cd28892ee54aba13e074f230709b2c3b87915ff36efd9be3ddfc603e92ecdda.JPG
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused --from nas-rsync NUMBER
+  
+ok
+~~~~
+
+"""]]
diff --git a/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment
new file mode 100644
index 000000000..192d48fc7
--- /dev/null
+++ b/doc/bugs/__34__old__34___and___34__new__34___hash_formats_are_mixed_up/comment_2_436d8994457517e4c6f68f572b83decc._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 2"
+ date="2014-08-24T22:26:47Z"
+ content="""
+Ok, I see, http://git-annex.branchable.com/internals/hashing/ says that old vs new hash mess is deliberate, to make user experience better. (One might ask why one hash was replaced with another equivalent, but nobody would. Oh wait, it's a filesystem case sensitivity issue of course. But it's too secret to be mentioned on \"hashing\" page.)
+
+\"unused --from=\" issue comes and goes, don't see it now. That initial issue of completely broken symlinks happened after running testremote, then breaking it (because it should say it takes hour(s) to complete). So, many users probably won't be affected (nevermind that those who will, will essentially have data loss).
+
+Last issue I faced that somehow my local working copy gets \"bare = true\" each time I sync against remote SSH repo (which is bare of course, as remote repo should be).
+
+"""]]
diff --git a/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
new file mode 100644
index 000000000..8d3c84024
--- /dev/null
+++ b/doc/forum/Using_the_Git-Annex_Assistant_as_a_Backup_and_Syncing_Service.mdwn
@@ -0,0 +1,5 @@
+I'm looking to use the Git-Annex Assistant to backup a single repository that is present on and synced between two computers (a home and a working computer). Ideally, each computer uses rsync.net for both of these service, while at the same time treating the cloud storage service as untrusted (so anything stored or tranferred through there is encrypted). Is it possible to do this using solely rsync.net (without the addition of some XMPP service)? According to the software, using shared encryption allows anyone with a clone of the repository to decrypt files on a remote, but the simplest way to make this clone seems to be to first clone to a removable drive, and then from the drive to the second computer (and then deleting the records of the clone to the drive). I'm unsure if by then setting up the backup at rsync.net for the second computer, whether the software will create a second backup that acts independently of the first, neglecting any syncing, or if it will recognize the backup as one of the same repository. I'm also unsure as to whether the software will even sync if the backup is recognized, or whether a tranfer repository at rsync.net is also necessary to complete the setup. Could you perhaps give me some advice on how to achieve this setup, or point me to some information that may help me along?
+
+(If the setup is unclear, I'm essentially trying to replicate something like SpiderOak with the Git-Annex Assistant, without using an XMPP service)
+
+[Edit: It may be easier to just use Git-Annex (no assistant), so that works too]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
new file mode 100644
index 000000000..e091460dc
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__.mdwn
@@ -0,0 +1 @@
+So, you provide ARM build. But you probably don't know that my NAS box runs OABI. No, you don't know, you can't know, and you shouldn't know. The only thing worth knowing is that writing great software in obscure and esoteric languages drastically limits its usage, impact, and collaboration around it. So, any idea of writing git-annex implementation in a sane, interpreted, "just works" language, e.g. Python? Thanks.
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
new file mode 100644
index 000000000..1cf6c84d6
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_1_29eda7ec1519f339d5b3601559fe0bb0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2014-08-24T10:41:58Z"
+ content="""
+> git-annex implementation in a sane, interpreted, \"just works\" language, e.g. Python? Thanks.
+
+Good luck finding anything that works on OARM. Python itself does not support OABI:
+
+> This issue remains as \"won't fix\". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python.
+
+(from <http://bugs.python.org/issue1762561#msg158974>)
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
new file mode 100644
index 000000000..32318b404
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_2_a2b2183ee86377cdfef7c3acbe9552fb._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 2"
+ date="2014-08-24T11:04:21Z"
+ content="""
+Python on this system \"just works\". That's because Python is a project with a real community, so if one pundit said \"not supported\", dozen of people shrugged and typed \"make\", then packed up result for thousands to use.
+
+But don't get carried away by OABI, that was just one random example how deployment of git-annex is problematic. There're bigger issues like community involvement, being able to investigate and resolve issues, submit patches, bring new working ideas, make git-annex development and lifecycle sustainable, in the end - as vividly cared by the author.
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
new file mode 100644
index 000000000..8e613dd21
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_3_5605d42a68b3140cb660eb710ce5031e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 3"
+ date="2014-08-24T18:29:23Z"
+ content="""
+Sure, that's the plan. But first I'm doing my homework to understand how it got to that and how community copes with that. Maybe I don't get something and every open-source project should have a notice like: \"Installation from scratch. This is not recommended.\" (http://git-annex.branchable.com/install/). Interested in building software you run? Interested to help? Get lost, you won't get it. Am I surprised? Nope, I'm doing my homework and know where that Haskell thing came from. A piece of Microsoft was largely involved with it, so no surprise of such attitudes.
+
+Surely I'm not the only one who got jaundiced eye on git-annex: https://github.com/tv42/big : \"big is not like git-annex, because: it's not written in Haskell, so it might even work across distribution upgrades and platforms\". Certainly, stories of cvsup and unison, which are now where they should be - rest in peace, didn't help. So, once again, I'm interested to know how other people deal with this lack of proper compilation instructions, ability to get simple and easy tweaks, etc. - short of not using it, which seems to be a popular choice, despite all the git-annex coolness (I for one have been having its deployment in my queue fro half a year, instead of spending exactly a weekend to do tweaks I need and contribute them back).
+
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
new file mode 100644
index 000000000..8afa4c6fb
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_4_f56508164c71b2080150bc354e5de4b7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T18:31:25Z"
+ content="""
+Previous comment was written in response to a comment suggesting me to rewrite it in Python myself - which was then removed for some reason.
+
+"""]]
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
new file mode 100644
index 000000000..e58191a7f
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_5_c8cdb0faa342fe1f9407ad4c97e6bc3c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.166"
+ subject="How I solved it..."
+ date="2014-08-26T23:03:09Z"
+ content="""
+I decided it was a bit harsh, so I removed comment. Here is how I solved problem:
+
+I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways.
+"""]]
diff --git a/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
new file mode 100644
index 000000000..dbe429fa9
--- /dev/null
+++ b/doc/future_proofing/comment_1_2614eb2e9b7b23fa9bb4251c0d025909._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~electrichead"
+ nickname="electrichead"
+ subject="Regarding accessing files in a time capsule..."
+ date="2014-08-25T15:51:00Z"
+ content="""
+Imagine a rather contrived doomsday scenario: the file paths and/or basenames are important and, for some reason, the symlinks are not present (perhaps they got deleted, or aren't supported). `git` and `git-annex` no longer exist and let's assume knowledge of `git` internals is not useful here. All the *content* is there, stored under hashed file names under `.git/annex/objects`.
+
+I may be missing something obvious but I think options for restoring file paths include:
+
+  - direct mode bypasses this issue; all the files are right there. 
+  - the WORM backend perhaps carries enough information in the object file names to work with.
+  - file content/metadata may be sufficient to easily recreate a sensible directory structure in some cases, so no worries.
+
+These first two options may represent compromises in various use-cases and the last may not be applicable or, if it is, practical. The object-path mapping could trivially be backed up in plain text in lieu of these. Like I said, I may be overlooking something here that makes this unnecessary or even a non-concern (actually, I've convinced myself it's not a serious concern in most of the use-cases I've considered, but crossing i's and dotting t's).
+"""]]
diff --git a/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
new file mode 100644
index 000000000..66615dac7
--- /dev/null
+++ b/doc/install/fromscratch/comment_4_765334858ef1eedff2c5d89ed42aa7f6._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawld54zdyk6b0W4jXnssSO_j2Nn3W1uVsUE"
+ nickname="Paul"
+ subject="comment 4"
+ date="2014-08-24T11:53:11Z"
+ content="""
+@azul, thanks for hints, but it still fails. No wonders though - this is Haskell, kids.
+
+~~~~
+$ cabal install git-annex --only-dependencies
+Resolving dependencies...
+cabal: Could not resolve dependencies:
+trying: git-annex-5.20140817
+trying: git-annex-5.20140817:+webapp
+trying: git-annex-5.20140817:+s3
+trying: git-annex-5.20140817:+dns
+trying: dns-1.4.3
+trying: yesod-1.2.6.1
+trying: yesod-auth-1.3.4.2
+trying: http-client-0.3.7.1
+trying: http-client-0.3.7.1:+network-uri
+trying: hS3-0.5.8
+trying: hxt-9.3.1.6
+trying: hxt-9.3.1.6:-network-uri
+rejecting: network-2.6.0.1, 2.6.0.0 (conflict: hxt-9.3.1.6:network-uri =>
+network>=2.4 && <2.6)
+rejecting: network-2.5.0.0, 2.4.2.3, 2.4.2.2, 2.4.2.1, 2.4.2.0, 2.4.1.2,
+2.4.1.1, 2.4.1.0, 2.4.0.1, 2.4.0.0, 2.3.2.0, 2.3.1.1, 2.3.1.0, 2.3.0.14,
+2.3.0.13, 2.3.0.12, 2.3.0.11, 2.3.0.10, 2.3.0.9, 2.3.0.8, 2.3.0.7, 2.3.0.6,
+2.3.0.5, 2.3.0.4, 2.3.0.3, 2.3.0.2, 2.3.0.1, 2.3 (conflict:
+http-client-0.3.7.1:network-uri => network>=2.6)
+rejecting: network-2.2.3.1, 2.2.3, 2.2.1.10, 2.2.1.9, 2.2.1.8, 2.2.1.7,
+2.2.1.6, 2.2.1.5, 2.2.1.4, 2.2.1.3, 2.2.1.2, 2.2.1.1, 2.2.1, 2.2.0.1, 2.2.0.0,
+2.1.0.0, 2.0 (conflict: dns => network>=2.3)
+~~~~
+
+"""]]
diff --git a/doc/todo/merge_in_ram___40__disk__41____63__.mdwn b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
new file mode 100644
index 000000000..a4a698a72
--- /dev/null
+++ b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
@@ -0,0 +1,5 @@
+git-annex is great. But for my repos the merge and recording state operations take forever.
+
+(merging fotos_enc_pg/synced/git-annex into git-annex...)
+
+Since git-annex is another branch (than master) and git usually needs a worktree for merging I assume that git-annex branch is temporarily checked out somewhere. Would it be possible to move this operation to RAM? Or a RAM-Disk?