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

4 files changed, 116 insertions, 0 deletions

diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
new file mode 100644
index 000000000..3cbee238c
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="annex.nrb@0b99c9078ef84fe229eb6f00841028a57dc07612"
+ nickname="annex.nrb"
+ subject="Should something else, not annex solve the ad hoc git use case?"
+ date="2015-11-17T10:02:24Z"
+ content="""
+Hi,
+
+I also struggle to be \"motivated by this use case\" here for Git-Annex.  As one who happens to be using git on files inside hiearchies I'd like to annex (without the gits).  Like many others it seems I am searching for a better solution for my ad hoc gits generated locally for myself (a quick way of push cloning to a remote and auto syncing).  For me Git-annex to ignore .git is enough.  I'd rather have the lower complexity 'does one job well' than introduce a separate work around to the git inside git issue. 
+
+http://git-annex.branchable.com/forum/Git_repos_in_git_annex__63__/?updated#comment-9fca5cf31ccfd3d78c78cb65f7672340
+
+http://git-annex.branchable.com/forum/Storing_git_repos_in_git-annex/
+
+I would see the pain coming from attemting to solve the user issue of git corruption: \"I put a git repo where it could get changed outside of git or by two gits concurrently\" and then it did and became a source of confusion.
+
+For me the ideal case is when annex is set up to ignore any .git hierarchy and does not attempt to handle location tracking of (for me ad hoc) git repos inside an annex tree.  As I understand it Annex has to anyway for git, but I would also generalise for other DCVS'.
+
+Sparkleshare may have hit the same 'issue' and talked about renaming the .gits internally for synchronisation.  I am interested to see if that separates sparkeleshare from the \"source of confusion\".
+
+I do use Dropbox where it does simply put its own version control of sorts on top of any git files, leaving the user free to sort out any sources of confusion.  In users eyes it millions of users level bug free, and any problem thus must be their own.
+
+For me, doing it like Dropbox, would not remove the \"source of confusion\", rather encourage it: and being git based, some users may conclude that Annex should handle it better.
+
+Then it would be a big ask of Annex to e.g. find gits and handle them as remotes of each other and auto sync; or lock access to the git bunch of files (a la Clearcase Multisite Master Replica) or detect and bifurcate before any conflict is hit or any other option that is not obvious or easy to me.
+
+It leads me to the view that ignoring .git files and hierarchies is the feature Annex should have.  We handle our ad-hoc gits inside annex tree use case separately.
+
+BR/ Nigel
+"""]]
diff --git a/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment b/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment
new file mode 100644
index 000000000..afce0e567
--- /dev/null
+++ b/doc/forum/Desktop_as_transfer_repository/comment_1_b211b8f0ab58b8e59ce31d6ed6cb3c8c._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="juh"
+ subject="My current workflow"
+ date="2015-11-17T14:47:59Z"
+ content="""
+Ok,
+
+here is my current workflow to clarify my problem:
+
+On raspberrypi:
+
+    Adding new podcasts
+    git annex sync
+
+On desktop:
+
+    git annex sync
+    git annex get --want-get
+
+New podcast content from raspberrypi is downloaded.
+
+In backup:
+
+    git annex sync
+    git annex get --want-get
+
+New podcast content from desktop is downloaded.
+
+On desktop:
+
+    git annex drop
+
+Everything on desktop is dropped.
+
+**Now the problem**
+
+Next time I do 
+
+    git annex get --want-get
+
+on **desktop** all files are downloaded again from either backup or raspberrypi.
+
+What can I do to have only content in desktop that is not in the raspberrypi repository or in the backup repository? 
+
+I thought that this is the behaviour of a transfer repository.
+"""]]
diff --git a/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment
new file mode 100644
index 000000000..cad2b2493
--- /dev/null
+++ b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_4_616cb76a510fa32c2aa48c25d24c6044._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Agenta"
+ subject="comment 4"
+ date="2015-11-17T10:32:41Z"
+ content="""
+Dear r,
+
+I did lots of testing about recovering deleted files or previous versions with git-annex but I didn't have much success. I really found it difficult to recover files from git-annex, too time consuming.
+At the end I found a chep and dirty solution. I write it here in case it may be useful to you or to somone else. I now run a daily backup of my git-annex repo with Bup (http://bup.github.io/) on a couple of my computers, so I can easily restore to a previous state if needed. Bup implements data deduplication so you can have daily backups without consuming too much space. Bup is extremely easy to use too, you can mount backups as fuse filesystems or view them via a web browser. The only problem with this approach is that if you change a file multiple times during a day you won't be able to recover those changes.
+"""]]
diff --git a/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment b/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment
new file mode 100644
index 000000000..e8102ff24
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_5_ba7d08b2bcb6614102c48b4cb3de5b1a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-11-18T14:55:33Z"
+ content="""
+The use case is only very silly - I just wanted to look directly at the data stored at that IPFS hash - it was not important and certainly not worth changing the way git-annex stores its keys.
+
+On a new machine with a new version of git-annex, I can no longer initialize a new IFPS remote:
+
+    ⟫ ipfs version
+    ipfs version 0.3.10-dev
+
+    ⟫ git annex version
+    git-annex version: 5.20151116-gbe86081
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser Database
+    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
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+    ⟫ git annex initremote ipfs type=external externaltype=ipfs encryption=none
+    initremote ipfs 
+    git-annex: git-annex-remote-ipfs: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)
+    failed
+    git-annex: initremote: 1 failed
+
+It looks like I'm missing a binary somewhere, but I'm not sure which one is missing.
+"""]]