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

8 files changed, 147 insertions, 0 deletions

diff --git a/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn b/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn
new file mode 100644
index 000000000..b92b32ab4
--- /dev/null
+++ b/doc/bugs/Wrong_backend_extension_in_files_with_multiple_dots.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+When `git-annex add`ing files with multiple dots in them, the `SHA256E`, `MD5E` (and presumably other `*E`) backends take the extension from the second-to-last dot, instead of the last dot.
+This annoyed me because I have some photographs with names like `YYYY-mm-dd HH.MM.SS.jpg`. However, it might be intentional considering a `file.tar.gz` would have `tar.gz`.
+
+### What steps will reproduce the problem?
+[[!format sh """
+$ touch a a.b a.b.c a.b.c.d
+$ git-annex add .
+add a ok
+add a.b ok
+add a.b.c ok
+add a.b.c.d ok
+$ git-annex lookupkey *
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.b.c
+SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.c.d
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+[[!format sh """
+$ git-annex version
+git-annex version: 6.20170101+gitg93d69b1-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: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+NeuroDebian's `git-annex-standalone` package on Xubuntu 16.04. (Also with a Debian sid chroot with their own `git-annex 6.20161210-1`)
+
+### 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'm trying to analyze and organize my huge `Photos` folder into a neat git-annex repository (with yet another [project of mine](https://www.github.com/alpernebbi/albumin)). It's a huge mess.
+
+Keep up the great work! Also thanks for fixing [my UTF-8 problem](https://git-annex.branchable.com/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/) as well. 
diff --git a/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment b/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment
new file mode 100644
index 000000000..7978244f9
--- /dev/null
+++ b/doc/bugs/assistant_crashes_in_TransferScanner/comment_17_fc141f396d2b9a27f6668d1b10836ea5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="johannes@12f1850a57e13cc234b5ebf88a5d3ac68915a6c2"
+ nickname="johannes"
+ avatar="http://cdn.libravatar.org/avatar/7acaf4a71b0b93cc419195f58f4cd54c"
+ subject="Solution"
+ date="2017-01-06T12:19:46Z"
+ content="""
+After the update to 20161231, I tried again. Unfortunately, I am still getting the same error.
+
+However, I noticed that removing the file for which I get the \"is outside repository\" error actually fixes the problem. Once I dropped the file from the annex as well, I was able to re-add the file without triggering this error again.
+
+Please consider this issues as fixed.
+"""]]
diff --git a/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment
new file mode 100644
index 000000000..28e329632
--- /dev/null
+++ b/doc/bugs/git-annex__58___unable_to_decommit_memory__58___Invalid_argument/comment_3_d5aead37bf76aaa194b3aea9aab0dd19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da"
+ subject="fresh git annex standalone  was uploaded to NeuroDebian"
+ date="2017-01-03T16:03:52Z"
+ content="""
+just uploaded 6.20170101+gitg93d69b1-1~ndall+1 which was built using ghc 8.0.1-17 on stretch.  Enjoy
+"""]]
diff --git a/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
new file mode 100644
index 000000000..054447ead
--- /dev/null
+++ b/doc/bugs/tor_setup_needs_a_unique_magic-wormhole_appid.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+The new "tor onion server" setup function uses magic-wormhole to transfer the necessary keys and addresses (yay!). However it should really be using a distinct "app id". Magic-wormhole codes are scoped to a specific APPID, which means that someone using the normal CLI client (`wormhole send foo.jpg`) can get a wormhole code like "1-purple-kumquat", and someone doing a git-annex setup process can get a code like "1-green-mushroom", and they won't be competing with each other for the numeric channel-id.
+
+If magic-wormhole's file-transfer application got really popular, and there were thousands of simultaneous users, the file-transfer wormhole codes would grow to require three or four digits (e.g. "9134-purple-kumquat"), making them harder to type. But if git-annex uses a different APPID, then git-annex codes could continue to be short and easy, independent of contention for channel-ids on other applications.
+
+To tell magic-wormhole to use a different APPID, just do `wormhole --appid=$APPID send ...` or `wormhole --appid=$APPID receive ...`. APPIDs should be unique and scoped to an owner of some sort, so I'd recommend a DNS name or URL-shaped identifier, something like "git-annex.branchable.com/onion-setup". If you add a new distinct mode, one which doesn't interoperate with the current onion-setup mode, you can allocate a new APPID for that mode too (e.g. "git-annex.branchable.com/new-thing-setup").
+
+You'll have a compatibility hit when you land this: two applications using different APPIDs won't communicate, so e.g. git-annex before the patch won't do wormhole setups with git-annex after the patch.
+
+The --appid= feature was added in magic-wormhole 0.9.0, released 24-Dec-2016.
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+I haven't run git-annex's onion setup feature directly, but I'm reading through the source code from current git, cd8d905f3418b9c6a6c658a0c7256ae6f5066310, Utility/MagicWormhole.hs, and I don't see anything that adds an --appid argument. (I don't know Haskell at all, so I apologize if it's already doing --appid and I'm just not looking in the right place).
+
+### 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)
+
+It looks pretty amazing! Looking forward to using it in a Dropbox-like synchronization context soon.
+
+
diff --git a/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
new file mode 100644
index 000000000..ccb079ed5
--- /dev/null
+++ b/doc/devblog/day_442__xmpp_removal/comment_1_22ff11b84f855ab5e6de6dcf2553a050._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="Apichat"
+ avatar="http://cdn.libravatar.org/avatar/af7b465d7cd067b9c5acd365bdef92ac"
+ subject="Maintain the XMPP function ?"
+ date="2017-01-05T14:00:34Z"
+ content="""
+Is it realy a good idea to remove now the XMPP function ? While XMPP is a good tool to manage social relations and is getting improve ? [As you say it is an easy way to share with friends](http://joeyh.name/blog/entry/p2p_dreams/)
+
+The lake of use of the XMPP function in Git-annex is may be due to the fact that Git-annex assistant and the XMPP feature are difficult to use on Windows - so 90% of social relations can't exist.
+
+Can't you a least maintain the XMPP function ?
+ 
+XMPP is getting improve a lot those years :
+
+  * Host services, finally we can easily use a host service up to date and with our own domain name :
+    * [[https://account.conversations.im/domain]]
+    * [[https://support-en.mailbox.org/knowledge-base/article/introduction-to-jabber]]
+    * [[https://gultsch.de/compliance_ranked.html]]
+
+  * Protocol Specifications 
+    * [The State of Mobile XMPP in 2016](https://gultsch.de/xmpp_2016.html)
+
+  * Client software :
+    * [[https://conversations.im]]
+    * [[https://jitsi.org]]
+    * [[https://conversejs.org]]
+    * [Tor Messenger](https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger)
+
+  * Server software :
+    * [[https://prosody.im]]
+    * [[https://www.ejabberd.im]]
+    * [Mongoose IM platform](https://www.erlang-solutions.com/products/mongooseim.html)
+
+
+"""]]
diff --git a/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
new file mode 100644
index 000000000..1cf693b5f
--- /dev/null
+++ b/doc/forum/Synchronize_two_latops_with_a_ssh_remote.mdwn
@@ -0,0 +1,3 @@
+Using the command `git-annex webapp` I was able to configure a local repository on my laptop A that is synchronized with a remote repository using ssh. This latter has sync enabled and it is encrypted. I also put it in the *full backup* group.
+
+Now, I would like to synchronize my laptop B with the remote repository with ssh. Using the webapp, I tried to do the same thing I did with my laptop A. However now, my both laptop are synchronized with the remote repository but they do not share any file between them. How can I achieve that ?
diff --git a/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment b/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment
new file mode 100644
index 000000000..5810ccce5
--- /dev/null
+++ b/doc/news/version_6.20170101/comment_1_c7781a1185382b98dfcc16d4f615cc85._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="Gioele"
+ avatar="http://cdn.libravatar.org/avatar/af2f2ba0dafe4650011d20f2168d43cff773aba97f55ae5b252bb873f391c1e2"
+ subject="The `version` command reports 6.20161231-gc8eeb17da"
+ date="2017-01-03T11:13:32Z"
+ content="""
+If I run `git-annex version` I get `6.20161231-gc8eeb17da` instead of `6.20170101-something`. Not a big deal, but maybe somebody else may be confused by it.
+
+My `git-annex` binary comes from `git-annex-standalone-amd64.tar.gz` (SHA1 `4a82bb7d0276f387e72f8e09e0d2b1f35edb49bd`).
+"""]]
diff --git a/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
new file mode 100644
index 000000000..6b577d58b
--- /dev/null
+++ b/doc/special_remotes/S3/comment_28_163d81443ca5a05138e6f570b068ac6e._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="mca@8789632e0b00e8efb984c948c13d9de28665f534"
+ nickname="mca"
+ avatar="http://cdn.libravatar.org/avatar/758861fe4b6231b85e761a91d6f01a2e"
+ subject="https-only access, type=S3 port=443"
+ date="2017-01-05T13:10:43Z"
+ content="""
+(My own question, answered by Use The Source Luke method)
+
+If you need to point a `type=S3` special remote at a service which provides only https (in my case, a local CEPH RADOS gateway) then you can do it by setting `port=443`.
+
+This was implemented in 6fcca2f1 and next tag was 5.20141203 .  On Ubuntu, that version is available in Xenial but not Trusty.
+
+"""]]