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

3 files changed, 89 insertions, 0 deletions

diff --git a/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn
new file mode 100644
index 000000000..a351b0ae4
--- /dev/null
+++ b/doc/bugs/Debian_and_MacOSX_cannot_read_eachother__39__s_S3_credentials.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+I seem to be hitting a problem with the way git annex encrypts the credentials for S3 remotes. I am creating an S3 remote with shared encryption and embedded credentials. If I create the remote on MacOSX, enableremote fails on Debian. If I create the remote on Debian, enableremote fails on MacOSX with a similar error.  I can enable MacOSX created remotes on other MacOSX systems and Debian created remotes on other Debian systems. 
+The enableremote creates a .git/annex/creds/uuid file, but the contents are garbled.
+
+Could this be an issue with different versions of GPG on the systems? 
+
+### What steps will reproduce the problem?
+- New git annex remote on Debian.
+- Clone and git annex init on MacOSX
+- Create S3 remote on MacOSX with encryption=shared embedcreds=yes 
+- Git annex sync
+- On Debian  enable remote
+
+Alternatively, create the S3 remote on Debian, sync and enable remote on MacOSX
+
+### What version of git-annex are you using? On what operating system?
+    MacOSX
+    gpg (GnuPG/MacGPG2) 2.0.30
+    libgcrypt 1.6.6
+    git-annex version: 6.20170101
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents 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: darwin x86_64
+
+    Debian 7
+    gpg (GnuPG) 1.4.12
+    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
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Debian 7
+    $ git annex enableremote S3
+    enableremote S3 gpg: packet(2) with unknown version 13
+      gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
+    git-annex: bad creds
+    CallStack (from HasCallStack):
+      error, called at ./Creds.hs:116:22 in main:Creds
+
+ #   MacOSX
+    git annex enableremote S34
+    enableremote S34 gpg: [don't know]: invalid packet (ctb=6b)
+      gpg error above was caused by an old git-annex bug in credentials storage. Working around it..
+    git-annex: bad creds
+    CallStack (from HasCallStack):
+      error, called at ./Creds.hs:116:22 in main:Creds
+
+"""]]
+
+### 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! git annex has been enormously helpful. Thanks so much for this tool.
+
diff --git a/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment
new file mode 100644
index 000000000..182d19e2e
--- /dev/null
+++ b/doc/bugs/Too_difficult_if_not_impossible_to_explicitly_add__47__keep_file_under_git___40__not_annex__41___in_v6_without_employing_.gitattributes/comment_4_598622df322c56da71320d1b15e0348f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 4"
+ date="2017-02-09T09:05:34Z"
+ content="""
+I want to point out an issue, that seems to be unnoticed:
+While we (datalad) might be able to deal with this effect regarding git status in terms of space, it has another consequence. As the scripts are showing it also leads to the file marked as modified, if it is rewritten (very same content) and therefore leaves the repository dirty. To me this a pretty weird effect and I don't understand yet what this is caused by.
+"""]]
diff --git a/doc/todo/Alternative_mode_control_for_import/comment_3_cd4b0f6752457a70f2ab908d23913d76._comment b/doc/todo/Alternative_mode_control_for_import/comment_3_cd4b0f6752457a70f2ab908d23913d76._comment
new file mode 100644
index 000000000..09ce568ee
--- /dev/null
+++ b/doc/todo/Alternative_mode_control_for_import/comment_3_cd4b0f6752457a70f2ab908d23913d76._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 3"
+ date="2017-02-07T22:51:15Z"
+ content="""
+    An implementation of --mode=Did,Nsid seemed worth adding at first, perhaps as --reinject-duplicates. But thinking about it some more, that would be the same as
+
+        git annex reinject --known /path/*
+        git annex import /path/*
+
+
+--mode=Did,Nsid would be quite a bit faster because it wouldn't hash the files twice, which is an advantage this suggestion has over any multiple command alternative.
+
+If you want to keep it to certain points in space rather than deal with all combinations, you could whitelist which ones are acceptable and people can request more to be whitelisted as they discover use cases for those modes. The current commands would alias to the modes (which would also make their behaviour obvious if this alias is mentioned in the documentation).
+"""]]