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

3 files changed, 41 insertions, 0 deletions

diff --git a/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment
new file mode 100644
index 000000000..2466bd932
--- /dev/null
+++ b/doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="quisquous"
+ subject="comment 2"
+ date="2016-07-11T17:59:56Z"
+ content="""
+Perhaps running ````stack install git-annex```` (using the implicit global project) ignores the flags in stack.yaml, see [#1313](https://github.com/commercialhaskell/stack/issues/1313). Following your suggestion, I tried cloning the repo and building using `stack build` both with and without the XMPP flag. Without the flag works fine, it seems the default ````false```` setting form xmpp flag in stack.yaml is honored when building *this* way.
+
+In any case, this worked:
+
+````
+$ git clone git://git-annex.branchable.com/ git-annex
+$ cd git-annex
+$ git checkout 6.20160511
+$ stack build
+$ stack install
+````
+"""]]
diff --git a/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment
new file mode 100644
index 000000000..3d5860fd0
--- /dev/null
+++ b/doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2016-07-11T17:25:28Z"
+ content="""
+> git doesn't provide any command that outputs the repo version AFAIK, so it's not a useful precedent.
+
+well -- exactly that -- `git version` DOES NOT output repos (its index or whatnot) version HERE. It only provides information about git's version
+Either there is some git command which outputs repo (index, ...) version is somewhat independent.  But ok -- I don't care much enough, can take version from git config I guess indeed, even though 'annex info' seems to be the most logical location for that information to be provided from as well IMHO ;-)
+"""]]
diff --git a/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment
new file mode 100644
index 000000000..b871a772d
--- /dev/null
+++ b/doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="magibney@908c3d4677b9e87e203538d4d5e8c296255749a0"
+ nickname="magibney"
+ subject="comment 2"
+ date="2016-07-11T18:45:10Z"
+ content="""
+Exactly: shell scripting, \"big list of keys and want to narrow it to only keys that are present or missing\". 
+
+My motivating use case is as a sanity check that all keys have been successfully transferred on a Ceph S3 instance internally (i.e., `s3cmd cp s3://sourcebucket/[annex-key] s3://destbucket/[annex-key]`, without being read back to the local machine and separately written back up to a different bucket on the same server and locally deleted).  Post-transfer, I want to check that all keys are present as expected, but in the event that a failed transfer is detected, I'd like to be able to report a specific key back to the operator/calling script. 
+
+I'm thinking that if one is running `checkpresentkey` in batch mode (with multiple keys at once), there are many useful things one might want to do with the output that would require associating output status indicators with input keys; and since the output of `checkpresentkey --batch` is so terse, it could optionally be extended without too much parsing/escaping/etc complication. 
+
+Thanks for considering this, and apologies that the initial request was a bit cryptic about the use case! 
+"""]]