From d917958450f80be6ff05df26f8088f088077af5e Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:19:41 +0000 Subject: removed --- .../comment_19_cdf3062fb82078ad5677b82dc5933560._comment | 13 ------------- 1 file changed, 13 deletions(-) delete mode 100644 doc/direct_mode/comment_19_cdf3062fb82078ad5677b82dc5933560._comment diff --git a/doc/direct_mode/comment_19_cdf3062fb82078ad5677b82dc5933560._comment b/doc/direct_mode/comment_19_cdf3062fb82078ad5677b82dc5933560._comment deleted file mode 100644 index 1b82f87d1..000000000 --- a/doc/direct_mode/comment_19_cdf3062fb82078ad5677b82dc5933560._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="mitzip" - subject="comment 19" - date="2015-05-27T20:20:11Z" - content=""" -Thanks for correcting that, and thanks for the git-revert suggestion! - -I have a question about the usage of git-revert for my purposes. I'm wanting to bring back a version of a file at a certain commit (not the whole commit) and I found this in the git docs... - ->Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. - -That being said, should I still use `git revert` instead of `git checkout` because `git revert` will take care of making the new commit for me? -"""]] -- cgit v1.2.3 From 15065ae071705b33efc13db1fd2dd29efbb2361f Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 21:31:20 +0000 Subject: small wishlist on s3: readonly remote support --- doc/todo/credentials-less_access_to_s3.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/todo/credentials-less_access_to_s3.mdwn diff --git a/doc/todo/credentials-less_access_to_s3.mdwn b/doc/todo/credentials-less_access_to_s3.mdwn new file mode 100644 index 000000000..39835ac1f --- /dev/null +++ b/doc/todo/credentials-less_access_to_s3.mdwn @@ -0,0 +1,11 @@ +My situation is this: while i know i can *read and write* to [[special_remotes/S3]] fairly easily with the credentials, I cannot read from there from other remotes that do not have those credentials enabled. + +This seems to be an assumption deeply rooted in git-annex, specifically in `Remote/S3.hs:390`. + +It would be *very* useful to allow remotes to read from S3 transparently. I am aware of the tips mentionned in the comments of [[tips/publishing_your_files_to_the_public/]] that use the `addurl` hack, but this seems not only counter-intuitive, but also seem to add significant per-file overhead in the storage. It also requires running an extra command after every `git annex add` which is a problem if you are running the assistant that will add stuff behind your back. + +Besides, you never know if and when the file really is available on s3, so running addurl isn't necessarily accurate. + +How hard would it be to fix that in the s3 remote? + +Thanks! --[[anarcat]] -- cgit v1.2.3 From be0574f608158935762398acac5ef837778c41c0 Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:33:42 +0000 Subject: Added a comment: proper usage of git annex proxy to mimic undo --depth --- .../comment_19_b851fbb0a86639770e6432c6431480a3._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment diff --git a/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment b/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment new file mode 100644 index 000000000..4e0878b76 --- /dev/null +++ b/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="mitzip" + subject="proper usage of git annex proxy to mimic undo --depth" + date="2015-05-27T21:33:42Z" + content=""" +Thanks for correcting that, and thanks for the git-revert suggestion! + +I saw this in the `git revert` docs and thought that `git checkout annex/direct/master~$depth` might best suit my needs of restoring a previous version of a file. (I liked the idea of presenting the user with a depth rather than a hash.) + +>Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. + +What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. So annex, thorough as it is, creates a $filename.variant-local.ext file after the conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict because git knows exactly what's changing and from when, rather than just some new file content showing up from who knows where with `git checkout`. The issue it seems is that `git revert` works on a commit basis, while `git checkout` can operate on files. If I'm correct in this, does annex use one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. + +Though, I'm still not clear how to use the \"depth\" referencing with `git revert` rather than hashes. +"""]] -- cgit v1.2.3 From d8cc232487f9ecdc6493f49738e6136f4877a57d Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:36:08 +0000 Subject: removed --- .../comment_19_b851fbb0a86639770e6432c6431480a3._comment | 15 --------------- 1 file changed, 15 deletions(-) delete mode 100644 doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment diff --git a/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment b/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment deleted file mode 100644 index 4e0878b76..000000000 --- a/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="mitzip" - subject="proper usage of git annex proxy to mimic undo --depth" - date="2015-05-27T21:33:42Z" - content=""" -Thanks for correcting that, and thanks for the git-revert suggestion! - -I saw this in the `git revert` docs and thought that `git checkout annex/direct/master~$depth` might best suit my needs of restoring a previous version of a file. (I liked the idea of presenting the user with a depth rather than a hash.) - ->Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. - -What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. So annex, thorough as it is, creates a $filename.variant-local.ext file after the conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict because git knows exactly what's changing and from when, rather than just some new file content showing up from who knows where with `git checkout`. The issue it seems is that `git revert` works on a commit basis, while `git checkout` can operate on files. If I'm correct in this, does annex use one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. - -Though, I'm still not clear how to use the \"depth\" referencing with `git revert` rather than hashes. -"""]] -- cgit v1.2.3 From 80bf3d0b4e4b43788f83b1965816b3567caa2a05 Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:42:50 +0000 Subject: --- ...per_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn new file mode 100644 index 000000000..996c0e378 --- /dev/null +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -0,0 +1,15 @@ +Thanks for correcting that, and thanks for the `git-revert` suggestion! + +**Context: Creating an OSX GUI for assistant managed direct mode repos to help with restoring old file versions.** + +I saw this in the `git revert` docs and thought that `git annex proxy -- git checkout annex/direct/master~$depth -- $filename` might best suit my needs of restoring a previous version of a file. (I liked the idea of presenting the user with a depth rather than a hash.) + +>Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory. + +What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. + +So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict because git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. + +The issue it seems is that git revert works on a commit basis, while git checkout can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. + +Though, I'm still not clear how to use the "depth" referencing with git revert rather than hashes, any suggestions? -- cgit v1.2.3 From 953de0173c4f5af8a946a8cec29459097b6442ec Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:44:55 +0000 Subject: --- doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn index 996c0e378..fd2927c5d 100644 --- a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -1,4 +1,4 @@ -Thanks for correcting that, and thanks for the `git-revert` suggestion! +[Thanks Joey for correcting the docs on `git annex undo --depth`, and thanks for the `git-revert` suggestion as a replacement!](http://git-annex.branchable.com/direct_mode/#comment-b6dcfc80842008e7f9f5b8f612b27867) **Context: Creating an OSX GUI for assistant managed direct mode repos to help with restoring old file versions.** -- cgit v1.2.3 From 33a5cbc9061f159a7f08c62f5367ceecb6eb9fee Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:48:13 +0000 Subject: --- doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn index fd2927c5d..1112932be 100644 --- a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -8,7 +8,7 @@ I saw this in the `git revert` docs and thought that `git annex proxy -- git che What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. -So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict because git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. +So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict as git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. The issue it seems is that git revert works on a commit basis, while git checkout can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. -- cgit v1.2.3 From 9dda66df78db328d901a849410ef8b29df39dd0b Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:49:42 +0000 Subject: --- doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn index 1112932be..6a02fed78 100644 --- a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -10,6 +10,6 @@ What I've found is that your suggestion of `git revert` is nice because it would So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict as git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. -The issue it seems is that git revert works on a commit basis, while git checkout can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. +The issue it seems is that `git revert` works on a commit basis, while `git checkout` can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. Though, I'm still not clear how to use the "depth" referencing with git revert rather than hashes, any suggestions? -- cgit v1.2.3 From 15a21216fb21598e46a845249e9e2fefc12c4db6 Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 21:50:10 +0000 Subject: Added a comment --- .../comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/tips/publishing_your_files_to_the_public/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment diff --git a/doc/tips/publishing_your_files_to_the_public/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment b/doc/tips/publishing_your_files_to_the_public/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment new file mode 100644 index 000000000..bd77d03ce --- /dev/null +++ b/doc/tips/publishing_your_files_to_the_public/comment_5_29c3ee4aed6a5b53b6767a96a7b85ad9._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="https://id.koumbit.net/anarcat" + subject="comment 5" + date="2015-05-27T21:50:10Z" + content=""" +[registerurl](http://source.git-annex.branchable.com/?p=source.git;a=blobdiff;f=doc/git-annex.mdwn;h=c33633e03378b0125a3feb5d1a9fa61ce9bfa9cc;hp=3af9bbb8c1d2e84506f3db80ad7253a7cd8de1d4;hb=abfe3c09b2caac0827a2196076c9bd9185451b9f;hpb=b24bb6b435ddc91510163c7b22db2ba52703724c) may provide a faster version of the above. i've also creted a [[feature request|todo/credentials-less_access_to_s3]] to make this easier with s3 (so that we don't have to setup urls for each individual file). --[[anarcat]] +"""]] -- cgit v1.2.3 From 8d1fa8a05ff965d6bf3a29eb4dd66b1a4d7d3cc9 Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 22:43:03 +0000 Subject: --- doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn index 6a02fed78..1f15d6655 100644 --- a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -12,4 +12,4 @@ So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after The issue it seems is that `git revert` works on a commit basis, while `git checkout` can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`. -Though, I'm still not clear how to use the "depth" referencing with git revert rather than hashes, any suggestions? +Though, I'm still not clear how to use the "depth" referencing with `git revert` rather than hashes, any suggestions? -- cgit v1.2.3 From 004436fcb0f3e21af1c7329988b8379738a53f57 Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 23:28:11 +0000 Subject: some dumb question, probably :/ sorry if i missed something obvious --- doc/forum/how_do_automated_upgrades_work__63__.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/forum/how_do_automated_upgrades_work__63__.mdwn diff --git a/doc/forum/how_do_automated_upgrades_work__63__.mdwn b/doc/forum/how_do_automated_upgrades_work__63__.mdwn new file mode 100644 index 000000000..1f404d144 --- /dev/null +++ b/doc/forum/how_do_automated_upgrades_work__63__.mdwn @@ -0,0 +1,11 @@ +When i start the assistant, it's nicely telling me: + +
+[2015-05-27 20:15:20 UTC] Upgrader: An upgrade of git-annex is available.  (version 5.20150522)
+
+ +That's really cool, but it's not actually upgrading. I looked around the website to understand how that worked and i found [[git-annex-upgrade]] and [[upgrades]] but those pages were not really useful, as they talk more about repository upgrades, and not the automated upgrade system. I was expecting [[upgrades]] to talk a bit about automated upgrades, or maybe the [[install]] page... + +i am running `5.20150508-g883d57f`, with a standalone image installed by root in `/opt`. Should that directory be writable by the user running git-annex to solve this? + +Thanks! --[[anarcat]] -- cgit v1.2.3 From 80da96ae178f39f5301f6bbb518bccbe3df36fb6 Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 23:32:18 +0000 Subject: Added a comment: bup-cron has something --- .../comment_1_99e359976acbdb9727598f8a87027de0._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment diff --git a/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment b/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment new file mode 100644 index 000000000..3f849e73e --- /dev/null +++ b/doc/devblog/day_288__microrelease_prep/comment_1_99e359976acbdb9727598f8a87027de0._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="https://id.koumbit.net/anarcat" + subject="bup-cron has something" + date="2015-05-27T23:32:18Z" + content=""" +so the bup people has a little [bup-damage](https://github.com/bup/bup/blob/master/cmd/damage-cmd.py) command to insert noise into files. it doesn't simulate I/O problems per se, but maybe it could help? --[[anarcat]] +"""]] -- cgit v1.2.3 From 964d6b263fb75f0805f1755121e488c3e973de4f Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 23:46:23 +0000 Subject: explain how to use registerurl --- doc/tips/publishing_your_files_to_the_public.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/tips/publishing_your_files_to_the_public.mdwn b/doc/tips/publishing_your_files_to_the_public.mdwn index ae65263a7..09f83bce0 100644 --- a/doc/tips/publishing_your_files_to_the_public.mdwn +++ b/doc/tips/publishing_your_files_to_the_public.mdwn @@ -61,3 +61,17 @@ To enable use a private S3 bucket for the remotes and then pre-sign actual URL w Example: key=`git annex lookupkey "$fname"`; sign_s3_url.bash --region 'eu-west-1' --bucket 'mybuck' --file-path $key --aws-access-key-id XX --aws-secret-access-key XX --method 'GET' --minute-expire 10 + +## Adding the S3 URL as a source + +Assuming all files in the current directory are available on S3, this will register the public S3 url for the file in git-annex, making it available for everyone *through git-annex*: + +
+bucket=yourbucketname
+find * -type l | while read file ; do
+  key=$(git annex lookupkey $file)
+  echo $key https://$bucket.s3.amazonaws.com/$key
+done | git annex registerurl
+
+ +`registerurl` was introduced in `5.20150317`. There's a todo open to ensure we don't have to do this by hand: [[todo/credentials-less access to s3]]. -- cgit v1.2.3 From 6ae34f8f05538e64d3e17590305f9d86b0bd3c04 Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 27 May 2015 23:48:02 +0000 Subject: follow the existing examples --- doc/tips/publishing_your_files_to_the_public.mdwn | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/doc/tips/publishing_your_files_to_the_public.mdwn b/doc/tips/publishing_your_files_to_the_public.mdwn index 09f83bce0..d2c074503 100644 --- a/doc/tips/publishing_your_files_to_the_public.mdwn +++ b/doc/tips/publishing_your_files_to_the_public.mdwn @@ -67,10 +67,9 @@ Example: Assuming all files in the current directory are available on S3, this will register the public S3 url for the file in git-annex, making it available for everyone *through git-annex*: 
-bucket=yourbucketname
-find * -type l | while read file ; do
+git annex find --in public-s3 | while read file ; do
   key=$(git annex lookupkey $file)
-  echo $key https://$bucket.s3.amazonaws.com/$key
+  echo $key https://public-annex.s3.amazonaws.com/$key
 done | git annex registerurl
-- cgit v1.2.3 From a4a208079916ebc1d42b5b77f677dc170e0af3a5 Mon Sep 17 00:00:00 2001 From: namelessjon Date: Thu, 28 May 2015 10:14:45 +0000 Subject: Added a comment --- .../comment_2_27a74d3926083a00c110aafea28420d7._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment diff --git a/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment b/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment new file mode 100644 index 000000000..461a86e8a --- /dev/null +++ b/doc/devblog/day_288__microrelease_prep/comment_2_27a74d3926083a00c110aafea28420d7._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="namelessjon" + subject="comment 2" + date="2015-05-28T10:14:45Z" + content=""" +https://stackoverflow.com/questions/1870696/simulate-a-faulty-block-device-with-read-errors ? +"""]] -- cgit v1.2.3 From fabd07e5ff083b8fc99de47d8162ab0e1ca2d9a6 Mon Sep 17 00:00:00 2001 From: eigengrau Date: Thu, 28 May 2015 13:09:23 +0000 Subject: Added a comment --- .../comment_3_dfcef745c92ec629f82ec6acc14d1519._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment diff --git a/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment new file mode 100644 index 000000000..ec277f9c2 --- /dev/null +++ b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="eigengrau" + subject="comment 3" + date="2015-05-28T13:09:23Z" + content=""" +Thanks! If it’s just for one file, it’s probably okay to move it to bad. If the error was intermittent, one can try reinjecting the content. + +As for the risk of overkill, I don’t know enough about how the SATA/SCSI subsystem handles things. The cornercase would be one where (say due to EM interference) the SATA connection is reset and the device driver reports read errors for lots and lots of files, but the drive comes back in time so that these files are erroneously moved to bad. However, I guess you do the “move to bad” action file by file, and the whole fsck fails if moving to bad fails. In this case, we probably wouldn’t bite the cornercase, because when the drive comes back online, at most one file is moved to “bad“ erroneously. +"""]] -- cgit v1.2.3 From 56d65a425c9461c88587d070cc732dc49a1d674f Mon Sep 17 00:00:00 2001 From: eigengrau Date: Thu, 28 May 2015 13:44:32 +0000 Subject: Added a comment --- .../comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment diff --git a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment new file mode 100644 index 000000000..8d489927f --- /dev/null +++ b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="eigengrau" + subject="comment 2" + date="2015-05-28T13:44:32Z" + content=""" +This would be absolutely awesome, because it would pruning away old data based on cut-offs. One could squash all history beyond some cut-off point. Or, probably better, one could preserve git history, but supply “git annex fsck” with a cut-off switch that specifies a date or time interval. All data referred to in commits older than the specified interval is then considered unused. +"""]] -- cgit v1.2.3