mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2016-07-11 18:48:44 -04:00
commit bc54666002
Failed to extract signature
3 changed files with 41 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
doc/bugs/does_not_build_on_OpenBSD_5.9/comment_2_c6521306cbee2e398998cd2eec4e47ca._comment Normal file
View file

@ -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
````
"""]]

10
doc/todo/git_annex_info_to_include_information_about_repo_version__63__/comment_4_5b3e45c746e6cfa7f511790bbd9f6c9f._comment Normal file
View file

@ -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 ;-)
"""]]

14
doc/todo/wishlist__58___optionally_print_key_in_output_of_checkpresentkey_batch_mode/comment_2_bb756ddf06c52ca52d73af319f0265b0._comment Normal file
View file

@ -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!
"""]]