From 78042d940ef2e02c736e1d02afddc214cf6ae603 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" Date: Mon, 11 Jul 2016 17:25:28 +0000 Subject: Added a comment --- .../comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment 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 ;-) +"""]] -- cgit v1.2.3 From 2d0570c6d897c6dbc7faa5b6112e1f4650a540bf Mon Sep 17 00:00:00 2001 From: quisquous Date: Mon, 11 Jul 2016 17:59:56 +0000 Subject: Added a comment --- .../comment_2_c6521306cbee2e398998cd2eec4e47ca._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment 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 +```` +"""]] -- cgit v1.2.3 From 896f7e716d0469c6d3d791dcf867855ea7c3229a Mon Sep 17 00:00:00 2001 From: "magibney@908c3d4677b9e87e203538d4d5e8c296255749a0" Date: Mon, 11 Jul 2016 18:45:11 +0000 Subject: Added a comment --- .../comment_2_bb756ddf06c52ca52d73af319f0265b0._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment 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! +"""]] -- cgit v1.2.3