doc: perl -p -i -e s/certianly/certainly/

48 files changed, 48 insertions, 48 deletions

diff --git a/doc/bugs/Assistant_uses_obsolete_GDU_volume_monitor/comment_3_d86aba42d014c4b4f708dcb5fe86e055._comment b/doc/bugs/Assistant_uses_obsolete_GDU_volume_monitor/comment_3_d86aba42d014c4b4f708dcb5fe86e055._comment
index c1bc52f2c..6256086c7 100644
--- a/doc/bugs/Assistant_uses_obsolete_GDU_volume_monitor/comment_3_d86aba42d014c4b4f708dcb5fe86e055._comment
+++ b/doc/bugs/Assistant_uses_obsolete_GDU_volume_monitor/comment_3_d86aba42d014c4b4f708dcb5fe86e055._comment
@@ -6,5 +6,5 @@
  content="""
 I've just committed support for using the new name. I've not been able to test it yet, as I don't have a new enough gnome here. Any testing you can do much appreciated.
 
-Leaving this bug open until it gets tested, and also because it's certianly appealing to just use poll rather than this fragile dbus stuff. And in any case, should add OSX support.
+Leaving this bug open until it gets tested, and also because it's certainly appealing to just use poll rather than this fragile dbus stuff. And in any case, should add OSX support.
 """]]
diff --git a/doc/bugs/Finding_an_Unused_file.mdwn b/doc/bugs/Finding_an_Unused_file.mdwn
index 211755829..c0e613163 100644
--- a/doc/bugs/Finding_an_Unused_file.mdwn
+++ b/doc/bugs/Finding_an_Unused_file.mdwn
@@ -146,7 +146,7 @@ upgrade supported from repository versions: 0 1 2
 """]]
 
 > If `git log -S` does not find the key, then it was not used for any
-> commit currently in the git repository. Which is certianly possible;
+> commit currently in the git repository. Which is certainly possible;
 > for example `git annex add file; git rm file`.
 > 
 > This is a dup of [[todo/wishlist: option to print more info with 'unused']]; [[done]] --[[Joey]] 
diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment
index e8a5f8cdd..a323d7835 100644
--- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment
+++ b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted:_uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment
@@ -19,7 +19,7 @@ GIT_INDEX_FILE='/home/foo/annex/.git/annex/index'
 --git-dir=/home/foo/annex/.git --work-tree=/home/foo/annex commit --quiet --allow-empty -m created repository
 </pre>
 
-This certianly looks like the index file setting for the git-annex branch is somehow leaking out past the branch commit operations. It continued setting that while setting up `gc.auto`; the next call to git after that stopped setting the index file.
+This certainly looks like the index file setting for the git-annex branch is somehow leaking out past the branch commit operations. It continued setting that while setting up `gc.auto`; the next call to git after that stopped setting the index file.
 
 The only way I can see offhand this could possibly happen is due to an exception. It may be that on ubuntu an exception is thrown by code that runs a git command with the index file set, for whatever reason, and this causes the code that normally resets it back to not run.
 
diff --git a/doc/bugs/Glacier_remote_uploads_duplicates/comment_7_e96187bad3dae2f5f95118f6df87a1ec._comment b/doc/bugs/Glacier_remote_uploads_duplicates/comment_7_e96187bad3dae2f5f95118f6df87a1ec._comment
index 618f35765..26cbb5a47 100644
--- a/doc/bugs/Glacier_remote_uploads_duplicates/comment_7_e96187bad3dae2f5f95118f6df87a1ec._comment
+++ b/doc/bugs/Glacier_remote_uploads_duplicates/comment_7_e96187bad3dae2f5f95118f6df87a1ec._comment
@@ -6,5 +6,5 @@
  content="""
 Ok, I've merged the glacier branch into master. I would still be happy to see some testing of this before my next release (in a week).
 
-I guess I'll close this bug report. There are certianly still problems that can happen if there are multiple repositories all writing to glacier independently. Seems to me that one good way to deal with this is to set up a single remote that is configured to be a gateway to glacier.
+I guess I'll close this bug report. There are certainly still problems that can happen if there are multiple repositories all writing to glacier independently. Seems to me that one good way to deal with this is to set up a single remote that is configured to be a gateway to glacier.
 """]]
diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
index 5b355e070..2be39d451 100644
--- a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
+++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time/comment_2_ead9fa75a12ef36be9a92637b144e74f._comment
@@ -6,7 +6,7 @@
  content="""
 This turns out to be much worse in direct mode than in indirect mode.
 
-In indirect mode, it only does extra work during the full startup scan. Suppose there are 3 files with the same content, 1, archive/2, and 3. It will download 1, and then will drop archive/2, and then will download 3. This certianly is not ideal, especially when the file content is large.
+In indirect mode, it only does extra work during the full startup scan. Suppose there are 3 files with the same content, 1, archive/2, and 3. It will download 1, and then will drop archive/2, and then will download 3. This certainly is not ideal, especially when the file content is large.
 
 In indirect mode, it continally and repeatedly downloads the drops the files, as long as it's running. Which is beyond unacceptable.
 
diff --git a/doc/bugs/JSON_output_broken_with___34__git_annex_sync__34__/comment_1_380a49b3c132f9f529729a1cb5a69621._comment b/doc/bugs/JSON_output_broken_with___34__git_annex_sync__34__/comment_1_380a49b3c132f9f529729a1cb5a69621._comment
index f0eff45c1..d1ad05842 100644
--- a/doc/bugs/JSON_output_broken_with___34__git_annex_sync__34__/comment_1_380a49b3c132f9f529729a1cb5a69621._comment
+++ b/doc/bugs/JSON_output_broken_with___34__git_annex_sync__34__/comment_1_380a49b3c132f9f529729a1cb5a69621._comment
@@ -4,5 +4,5 @@
  subject="comment 1"
  date="2012-11-27T21:13:08Z"
  content="""
-Yeah, so git-annex has --json as a option available to any command, but the set of commands where it's actually useful is rather smaller, and certianly does not include this one. In general there are quite a lot of places where third-party program output is allowed to show through to provide necessary progress or debugging output, and that of course makes the json mode invalid.
+Yeah, so git-annex has --json as a option available to any command, but the set of commands where it's actually useful is rather smaller, and certainly does not include this one. In general there are quite a lot of places where third-party program output is allowed to show through to provide necessary progress or debugging output, and that of course makes the json mode invalid.
 """]]
diff --git a/doc/bugs/Lost_S3_Remote/comment_1_6e80e6db6671581d471fc9a54181c04c._comment b/doc/bugs/Lost_S3_Remote/comment_1_6e80e6db6671581d471fc9a54181c04c._comment
index b4f7bdc3c..d6595ad5b 100644
--- a/doc/bugs/Lost_S3_Remote/comment_1_6e80e6db6671581d471fc9a54181c04c._comment
+++ b/doc/bugs/Lost_S3_Remote/comment_1_6e80e6db6671581d471fc9a54181c04c._comment
@@ -6,5 +6,5 @@
  content="""
 Despite `status` listing S3 support, your git-annex is actually built with S3stub, probably because it failed to find the necessary S3 module at build time. Rebuild git-annex and watch closely, you'll see \"** building without S3 support\". Look above that for the error and fix it.
 
-It was certianly a bug that it showed S3 as supported when built without it. I've fixed that.
+It was certainly a bug that it showed S3 as supported when built without it. I've fixed that.
 """]]
diff --git a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_20_b685050ee6fbb1a685e33f9656a10e84._comment b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_20_b685050ee6fbb1a685e33f9656a10e84._comment
index 0ef43779b..83ab46051 100644
--- a/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_20_b685050ee6fbb1a685e33f9656a10e84._comment
+++ b/doc/bugs/The_restricted_ssh_key_pair_makes_password_login___40__nearly__41___impossible/comment_20_b685050ee6fbb1a685e33f9656a10e84._comment
@@ -4,5 +4,5 @@
  subject="comment 20"
  date="2013-04-14T20:59:26Z"
  content="""
-Ok, I don't know how gnome-keyring communicates with ssh, but that's good enough evidence for me: It was certianly gnome-keyring that got us into this mess!
+Ok, I don't know how gnome-keyring communicates with ssh, but that's good enough evidence for me: It was certainly gnome-keyring that got us into this mess!
 """]]
diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
index 4eeedcd6b..e839e7a15 100644
--- a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
+++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_3_0a785b5dfbf4eef30854d6bedb12b7d1._comment
@@ -4,7 +4,7 @@
  subject="comment 3"
  date="2012-11-13T18:00:42Z"
  content="""
-I've tried & failed to reproduce this using the assistant. When I mark a repo as dead, and go into Configuration -> Manage repositories, the repository is not shown in the list of repositories it'll sync to, and it certianly doesn't upload any files to it.
+I've tried & failed to reproduce this using the assistant. When I mark a repo as dead, and go into Configuration -> Manage repositories, the repository is not shown in the list of repositories it'll sync to, and it certainly doesn't upload any files to it.
 
 
 """]]
diff --git a/doc/bugs/Truncated_file_transferred_via_S3/comment_1_5962358e6067448f633cc0eaf42f9ca7._comment b/doc/bugs/Truncated_file_transferred_via_S3/comment_1_5962358e6067448f633cc0eaf42f9ca7._comment
index 6a05b9750..f3583d31b 100644
--- a/doc/bugs/Truncated_file_transferred_via_S3/comment_1_5962358e6067448f633cc0eaf42f9ca7._comment
+++ b/doc/bugs/Truncated_file_transferred_via_S3/comment_1_5962358e6067448f633cc0eaf42f9ca7._comment
@@ -6,5 +6,5 @@
  content="""
 Did you get a chance to run `git annex fsck` on the file? I'd hope it would detect this problem.
 
-It's certianly possible for data to get corrupted somehow in transit. git-annex does not check that it got the expected contents until a fsck happens.
+It's certainly possible for data to get corrupted somehow in transit. git-annex does not check that it got the expected contents until a fsck happens.
 """]]
diff --git a/doc/bugs/With_S3__44___GPG_ask_for_a_new_passphrase/comment_2_e5d42b623017acedf6a3890ce15680a3._comment b/doc/bugs/With_S3__44___GPG_ask_for_a_new_passphrase/comment_2_e5d42b623017acedf6a3890ce15680a3._comment
index d742bbe58..7b26ca738 100644
--- a/doc/bugs/With_S3__44___GPG_ask_for_a_new_passphrase/comment_2_e5d42b623017acedf6a3890ce15680a3._comment
+++ b/doc/bugs/With_S3__44___GPG_ask_for_a_new_passphrase/comment_2_e5d42b623017acedf6a3890ce15680a3._comment
@@ -4,7 +4,7 @@
  subject="comment 2"
  date="2013-01-16T02:17:26Z"
  content="""
-Someone else reported what sounds like the same bug at [[encryption_given_a_gpg_keyid_still_uses_symmetric_encryption]]. It sounds like this is somehow an agent bug. I cannot reproduce it. I can hypothesise that, if this bug is occurring, you'll be prompted for a passphrase when running this command.. which if it happens would certianly be a bug in gpg or its agent
+Someone else reported what sounds like the same bug at [[encryption_given_a_gpg_keyid_still_uses_symmetric_encryption]]. It sounds like this is somehow an agent bug. I cannot reproduce it. I can hypothesise that, if this bug is occurring, you'll be prompted for a passphrase when running this command.. which if it happens would certainly be a bug in gpg or its agent
 
 touch foo; echo foo| gpg --symmetric --passphrase-fd=0 foo
 
diff --git a/doc/bugs/android:_high_CPU_usage__44___unclear_how_to_quit/comment_7_d38d6f40db4c9437764c7b2ddf36b5a9._comment b/doc/bugs/android:_high_CPU_usage__44___unclear_how_to_quit/comment_7_d38d6f40db4c9437764c7b2ddf36b5a9._comment
index 66a560191..819d31672 100644
--- a/doc/bugs/android:_high_CPU_usage__44___unclear_how_to_quit/comment_7_d38d6f40db4c9437764c7b2ddf36b5a9._comment
+++ b/doc/bugs/android:_high_CPU_usage__44___unclear_how_to_quit/comment_7_d38d6f40db4c9437764c7b2ddf36b5a9._comment
@@ -4,7 +4,7 @@
  subject="comment 7"
  date="2013-08-26T20:00:39Z"
  content="""
-It's certianly possible that the terminal app eats cpu for some reason even when sitting idle. It's hard for me to tell since I've been measuring cpu use by running top inside that terminal, which necessarily seems to use a lot of the CPU just to draw the screen.
+It's certainly possible that the terminal app eats cpu for some reason even when sitting idle. It's hard for me to tell since I've been measuring cpu use by running top inside that terminal, which necessarily seems to use a lot of the CPU just to draw the screen.
 
 If it's the terminal at fault, it would continue after you shutdown the git-annex daemon, since that doesn't close the terminal.
 """]]
diff --git a/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_7_0f4f471102e394ebb01da40e4d0fd9f6._comment b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_7_0f4f471102e394ebb01da40e4d0fd9f6._comment
index c3aee6c57..92b205bc3 100644
--- a/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_7_0f4f471102e394ebb01da40e4d0fd9f6._comment
+++ b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_7_0f4f471102e394ebb01da40e4d0fd9f6._comment
@@ -6,7 +6,7 @@
  content="""
 git 1.7.4 does not make things better. With it, if I add first \"X/foo\" and then \"x/bar\", it commits \"X/bar\".
 
-That will *certianly* cause problems when interoperating with a repo clone on a case-sensative filesystem, since
+That will *certainly* cause problems when interoperating with a repo clone on a case-sensative filesystem, since
 git-annex there will not see the location log that git committed to the wrong case directory.
 
 It's possible there is some interoperability problem when pulling from linux like you did, onto HFS+, too. I am not quite sure. Ah, I did find one.. if I clone the repo with \"X/foo\" in it to a case-sensative filesystem, and add a \"x/foo\" there,
diff --git a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
index 600044354..382f8c835 100644
--- a/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
+++ b/doc/bugs/git-annex_merge_stalls/comment_3_ced9b0d724fb55c756106b64c3721003._comment
@@ -12,7 +12,7 @@ joeyh for example, if you ran it and ctrl-z'd at just the right time, it could b
 joeyh (or the kernel coud have gotten confused, which given you also had a crash, who knows..)
 dp sounds logical
 joeyh forcing locks is always a problimatic thing
-joeyh but git-annex could certianly notice if it seems to be stalled and print some useful messages
+joeyh but git-annex could certainly notice if it seems to be stalled and print some useful messages
 joeyh and maybe have a way to run with locks forced
 </pre>
 """]]
diff --git a/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_1_8f081aeba7065d143a453dc128543f59._comment b/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_1_8f081aeba7065d143a453dc128543f59._comment
index 99bc8277d..89531ca16 100644
--- a/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_1_8f081aeba7065d143a453dc128543f59._comment
+++ b/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_1_8f081aeba7065d143a453dc128543f59._comment
@@ -14,5 +14,5 @@ The link that you show:
 
 If I understand you correctly, it's only happening with one particular file content.
 
-I think you either need to rule out it being due to the way you've installed git-annex, perhaps by installing the linux standalone tarball, and seeing if you can get the same behavior with that. Or you could send me the repository by email (joey@kitenet.net) and I'll see if I can reproduce it, and if so, will certianly be able to debug and fix it.
+I think you either need to rule out it being due to the way you've installed git-annex, perhaps by installing the linux standalone tarball, and seeing if you can get the same behavior with that. Or you could send me the repository by email (joey@kitenet.net) and I'll see if I can reproduce it, and if so, will certainly be able to debug and fix it.
 """]]
diff --git a/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_2_54a4b10723fd8a80dd486377ff15ce0d._comment b/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_2_54a4b10723fd8a80dd486377ff15ce0d._comment
index 1aefe452d..7ac34e751 100644
--- a/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_2_54a4b10723fd8a80dd486377ff15ce0d._comment
+++ b/doc/bugs/git_annex_add_removes_file_with_no_data_left/comment_2_54a4b10723fd8a80dd486377ff15ce0d._comment
@@ -4,7 +4,7 @@
  subject="comment 2"
  date="2013-07-18T19:46:12Z"
  content="""
-Hmm, given the size of the repo, please don't email it directly, if you choose to do that. But getting me access to it would certianly be useful.
+Hmm, given the size of the repo, please don't email it directly, if you choose to do that. But getting me access to it would certainly be useful.
 
 
 """]]
diff --git a/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_11_ad13e3221ae06086e86800316912d951._comment b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_11_ad13e3221ae06086e86800316912d951._comment
index ba2f442e4..301b0f973 100644
--- a/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_11_ad13e3221ae06086e86800316912d951._comment
+++ b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_11_ad13e3221ae06086e86800316912d951._comment
@@ -4,7 +4,7 @@
  subject="comment 11"
  date="2013-05-19T21:13:41Z"
  content="""
-You're certianly welcome.
+You're certainly welcome.
 
 So, you did not install git-annex from the dmg? That bundles its own gpg.
 
diff --git a/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment
index 80a047025..03f213c43 100644
--- a/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment
+++ b/doc/bugs/git_annex_fork_bombs_on_gpg_file/comment_6_7eb535ca38b3e84d44d0f8cbf5e61b8b._comment
@@ -8,7 +8,7 @@ So there are a lot of uploads attempts being made (and apparently failing), and
 
 The repeated \"(gpg)\" is an interesting clue, since normally git-annex only runs gpg once, to unlock an encrypted special remote's encryption key, and then should retain the key, cached in memory. I was able to reproduce this part of the bug (but not the zombie processes) when I purposfully broke the bup special remote by making it throw an error when it was supposed to run bup to send a file. That defeats the caching, since the state, including the cache, is thrown away when there's an exception. Working on a fix for that..
 
-That doesn't explain what's actually causing the problem for you, but it does certianly suggest the bup special remote code is failing in some unusual way. What happens if rather than starting the assistant, you use git-annex manually to send files to the remote? Run:
+That doesn't explain what's actually causing the problem for you, but it does certainly suggest the bup special remote code is failing in some unusual way. What happens if rather than starting the assistant, you use git-annex manually to send files to the remote? Run:
 
 <pre>
 git annex copy --to ffe41272-608e-43c4-8f35-e9cd63087892 --debug
diff --git a/doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn b/doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn
index 34096d894..3dc193683 100644
--- a/doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn
+++ b/doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn
@@ -70,7 +70,7 @@ index 7835988..ed8ea6c 100644
 
 Any update on this? Why is `-a` used here? -- [[anarcat]]
 
-> -a is not really the problem. You certianly do usually want
+> -a is not really the problem. You certainly do usually want
 > to commit your changes before converting to direct mode.
 > 
 > [[done]]; now when this happens it catches the exception and 
diff --git a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
index dccc5cd6a..1e2a8fe24 100644
--- a/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
+++ b/doc/bugs/non-repos_in_repositories_list___40__+_other_weird_output__41___from_git_annex_status/comment_4_d0e55585f1612148163039d157253258._comment
@@ -4,7 +4,7 @@
  subject="comment 4"
  date="2013-07-26T16:52:26Z"
  content="""
-The 4201 dangling blobs is a little bit strange, although it could certianly happen in some normal scenarios.
+The 4201 dangling blobs is a little bit strange, although it could certainly happen in some normal scenarios.
 Overall, your repository seems to be ok except for this weird data in the one file. I do not anticipate the extra garbage causing any problems at all.
 
 To track this down, we need to find the commit that added the garbage. One way, assuming you're using indirect mode, is to `git checkout git-annex; git blame uuid.log` and `git show` the commit that added the garbage. If you're using direct mode, you should first `git clone` the repository and do that in the clone.
diff --git a/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment b/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
index ecf697d2c..4582a3071 100644
--- a/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
+++ b/doc/bugs/remote_not_showing_up_in_webapp/comment_1_2a269732fd528f505777542d3556437a._comment
@@ -8,7 +8,7 @@ marcov does not show up in the webapp because there is no configured git remote
 
 This is a slightly confusing corner of the webapp. The webapp will show repositories that do not have a configured remote, but it only does it for special remotes. ssh repos, being regular git remotes, don't currently show up in the webapp unless that repository is actually set up as a remote.
 
-It should certianly not show it as \"unknown\"; it would be much better to use the full repo description here, since it does not have a remote name.
+It should certainly not show it as \"unknown\"; it would be much better to use the full repo description here, since it does not have a remote name.
 (Unless the description is really long!)
 
 I think you'll also get the \"unknown uuid\" screen even for a special remote that is not configured in the local repository. So that needs to be fixed.
diff --git a/doc/bugs/tmp_file_handling/comment_2_cc14c7a79a544e47654e4cd8abc85edd._comment b/doc/bugs/tmp_file_handling/comment_2_cc14c7a79a544e47654e4cd8abc85edd._comment
index e8e48abc8..d6ae5bcf0 100644
--- a/doc/bugs/tmp_file_handling/comment_2_cc14c7a79a544e47654e4cd8abc85edd._comment
+++ b/doc/bugs/tmp_file_handling/comment_2_cc14c7a79a544e47654e4cd8abc85edd._comment
@@ -4,5 +4,5 @@
  subject="comment 2"
  date="2012-10-24T15:50:40Z"
  content="""
-`rsynctmp` is only used when sending files to a rsync special remote. You can certianly delete it if you got a stale one, but the next time a file is sent to a rsync special remote it should delete it anyway.
+`rsynctmp` is only used when sending files to a rsync special remote. You can certainly delete it if you got a stale one, but the next time a file is sent to a rsync special remote it should delete it anyway.
 """]]
diff --git a/doc/bugs/utf8/comment_13_7044d2c5bb1c91ee37eb9868963a1ff2._comment b/doc/bugs/utf8/comment_13_7044d2c5bb1c91ee37eb9868963a1ff2._comment
index fce51ac32..651e43438 100644
--- a/doc/bugs/utf8/comment_13_7044d2c5bb1c91ee37eb9868963a1ff2._comment
+++ b/doc/bugs/utf8/comment_13_7044d2c5bb1c91ee37eb9868963a1ff2._comment
@@ -37,5 +37,5 @@ And still cannot replicate the bug; as expected it does not use the socket since
 
 copy foo (checking foo...) [2013-07-27 16:40:42 EDT] call: ssh [\"-T\",\"fozz@git-annex-markdown.lang.speechmarks.com-fozz_phone.2Dannex.IdWwlXHtSsjVUMcq\",\"git-annex-shell 'inannex' '' 'SHA256E-s29--093429efb0d1427753d1f038f5279ec4df66785a1b2429b3fa5e3a01bcb75bd8' --uuid 111\"]
 
-So, I don't understand how this could have happened. Although my recent changes mean it'll use a 62 byte path max on Android now, which certianly should avoid the problem, even if there's some actual bug here that I cannot reproduce.
+So, I don't understand how this could have happened. Although my recent changes mean it'll use a 62 byte path max on Android now, which certainly should avoid the problem, even if there's some actual bug here that I cannot reproduce.
 """]]
diff --git a/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment b/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
index a18fa95e3..716f7d99a 100644
--- a/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
+++ b/doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
@@ -4,5 +4,5 @@
  subject="comment 2"
  date="2012-11-09T21:55:42Z"
  content="""
-It does try to mark itself as extended away, but yes, I think this is a potential concern. If you find the assistant interacts badly with your other clients, you can certianly give it its own XMPP account.
+It does try to mark itself as extended away, but yes, I think this is a potential concern. If you find the assistant interacts badly with your other clients, you can certainly give it its own XMPP account.
 """]]
diff --git a/doc/design/assistant/blog/day_140__release_monday.mdwn b/doc/design/assistant/blog/day_140__release_monday.mdwn
index 5d732aef1..9c9ccd166 100644
--- a/doc/design/assistant/blog/day_140__release_monday.mdwn
+++ b/doc/design/assistant/blog/day_140__release_monday.mdwn
@@ -19,7 +19,7 @@ Still working on getting the standalone builds for this release done,
 should be done by the end of today.
 
 Also found a real stinker of a bug in `dirContentsRecursive`, which was
-just completely broken, apparently since day 1. Fixing that has certianly
+just completely broken, apparently since day 1. Fixing that has certainly
 fixed buggy behavior of `git annex import`. It seems that the other
 user of it, the transfer log code, luckily avoided the deep directory
 trees that triggered the bug.
diff --git a/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment b/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
index 1ebc78627..a2e64671f 100644
--- a/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
+++ b/doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
@@ -6,5 +6,5 @@
  content="""
 The [[bugs]] page is the place to put bug reports like this so I won't forget them.
 
-This should certianly not be happening. There are actually two git-annex processes running in the situation you describe; I'd be most curious to know whether the `git annex transfer` process was the one that blew up, or if the `git annex assistant` blew up. Also, it's not clear to me if you enabled the chunksize parameter when setting up the special remote, which could well be a significant detail.
+This should certainly not be happening. There are actually two git-annex processes running in the situation you describe; I'd be most curious to know whether the `git annex transfer` process was the one that blew up, or if the `git annex assistant` blew up. Also, it's not clear to me if you enabled the chunksize parameter when setting up the special remote, which could well be a significant detail.
 """]]
diff --git a/doc/design/assistant/blog/day_83__3-way.mdwn b/doc/design/assistant/blog/day_83__3-way.mdwn
index d58ec9fe5..9411c4c1c 100644
--- a/doc/design/assistant/blog/day_83__3-way.mdwn
+++ b/doc/design/assistant/blog/day_83__3-way.mdwn
@@ -68,6 +68,6 @@ still possible with other network topologies (ie, if D is connected to both
 B and C, there would be an upload loop 'B -> C -> D -> B`). So unless I can
 find a better event to hook into, this idea is doomed.
 
-I do have another idea to fix the same problem. C could certianly remember
+I do have another idea to fix the same problem. C could certainly remember
 that it saw a file and didn't know where to get the content from, and then
 when it receives a git push of a git-annex branch, try again.
diff --git a/doc/design/assistant/gpgkeys.mdwn b/doc/design/assistant/gpgkeys.mdwn
index e3f2a3a93..647d65083 100644
--- a/doc/design/assistant/gpgkeys.mdwn
+++ b/doc/design/assistant/gpgkeys.mdwn
@@ -7,7 +7,7 @@ To support using gpg keys in the assistant, we need some things:
 1. Help user set up a gpg key if they don't have one. This could be a
    special-purpose key dedicated to being used by git-annex. It might be
    nice to leave the user with a securely set up general purpose key,
-   but that would certianly preclude prompting for its password in the
+   but that would certainly preclude prompting for its password in the
    webapp. Indeed, the password prompt is the main problem here.
    Best solution would be to get gpg agent working on all supported 
    platforms.
diff --git a/doc/devblog/day_-4__forgetting.mdwn b/doc/devblog/day_-4__forgetting.mdwn
index 9cec51475..a37b32e33 100644
--- a/doc/devblog/day_-4__forgetting.mdwn
+++ b/doc/devblog/day_-4__forgetting.mdwn
@@ -72,7 +72,7 @@ feature.
   to handle this case, too..
 
 * For some reason the automatic transitioning code triggers
-  a "(recovery from race)" commit. This is certianly a bug somewhere,
+  a "(recovery from race)" commit. This is certainly a bug somewhere,
   because you can't have a race with only 1 participant.
 
 ----
diff --git a/doc/devblog/day_48__direct_mode_guard_design.mdwn b/doc/devblog/day_48__direct_mode_guard_design.mdwn
index bc2dbe316..c047e7f75 100644
--- a/doc/devblog/day_48__direct_mode_guard_design.mdwn
+++ b/doc/devblog/day_48__direct_mode_guard_design.mdwn
@@ -3,7 +3,7 @@ Preventing a stray `git commit -a` or `git add` doing bad things in a
 direct mode repository seems increasingly important.
 
 First, considered moving `.git`, so git won't know it's a git repository.
-This doesn't seem *too* hard to do, but there will certianly be unexpected
+This doesn't seem *too* hard to do, but there will certainly be unexpected
 places that assume `.git` is the directory name.
 
 I dislike it more and more as I think about it though, because it moves
diff --git a/doc/devblog/day_65__wrapping_up_upgrades.mdwn b/doc/devblog/day_65__wrapping_up_upgrades.mdwn
index b5bb62d6d..2c3816f0a 100644
--- a/doc/devblog/day_65__wrapping_up_upgrades.mdwn
+++ b/doc/devblog/day_65__wrapping_up_upgrades.mdwn
@@ -1,5 +1,5 @@
 [[!img assistant/upgradecomplete.png]]
 
 Upgrades are fully working on Linux. OSX code is written but intested and I
-thought of one bug it certianly has on my evening walk. Probably another
+thought of one bug it certainly has on my evening walk. Probably another
 hour's work left later this evening to finsh it off.
diff --git a/doc/devblog/day_9__Friday_the_13th.mdwn b/doc/devblog/day_9__Friday_the_13th.mdwn
index b8fe4bc19..77d9039eb 100644
--- a/doc/devblog/day_9__Friday_the_13th.mdwn
+++ b/doc/devblog/day_9__Friday_the_13th.mdwn
@@ -10,7 +10,7 @@ But, I got distracted chasing down some bugs on Windows. These were
 quite ugly; more direct mode mapping breakage which resulted in 
 files not being accessible. Also fsck on Windows failed to detect and fix
 the problem. All fixed now. (If you use git-annex on Windows, you should
-certianly upgrade and run `git annex fsck`.)
+certainly upgrade and run `git annex fsck`.)
 
 As with most bugs in the Windows port, the underlying cause turned out to
 be stupid: `isSymlink` always returned False on Windows. Which makes sense
diff --git a/doc/forum/A_question_an_the_nomad_use_cases:_files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment b/doc/forum/A_question_an_the_nomad_use_cases:_files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
index 3eb2697a6..e29f57657 100644
--- a/doc/forum/A_question_an_the_nomad_use_cases:_files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
+++ b/doc/forum/A_question_an_the_nomad_use_cases:_files_to_fetch__44___files_to_delete__44___files_to_keep__63__/comment_1_fe291cd6cd8e2d5b8e23f8e3689d824b._comment
@@ -11,5 +11,5 @@ What you might be looking for is `git annex drop foo; rm foo`, followed by a git
 The assistant isn't really about only keeping a subset of files on your laptop. It would like to get them all, except for ones in \"archive\" directories.
 You can configure the assistant to use manual mode, and then it doesn't download any files on its own (so you have to manually `git annex get` them), but it will still handle all the other stuff the assistant does, like automatically committing and syncing changes.
 
-An archive repository wants one copy of every file that is not already stored in some other archive repository. So an archive repository could certianly be used instead of a transfer repository. (But not a small archive repository; those only want files that are moved to \"archive\" directories.) A better choice might be to make that server be a backup repository. That makes it want *every* file, no matter what, and it follows that it would archive everything, and have everything the client wants available for transferring to it.
+An archive repository wants one copy of every file that is not already stored in some other archive repository. So an archive repository could certainly be used instead of a transfer repository. (But not a small archive repository; those only want files that are moved to \"archive\" directories.) A better choice might be to make that server be a backup repository. That makes it want *every* file, no matter what, and it follows that it would archive everything, and have everything the client wants available for transferring to it.
 """]]
diff --git a/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment b/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
index 1e4cbbf97..d4e406829 100644
--- a/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
+++ b/doc/forum/Change_remote_server_address/comment_1_401c3d2530ac7ba41dd3857ab4737ed5._comment
@@ -4,7 +4,7 @@
  subject="comment 1"
  date="2013-11-01T16:35:47Z"
  content="""
-Yes, you can certianly edit .git/config in any way you like and the assistant will use the new values when started back up.
+Yes, you can certainly edit .git/config in any way you like and the assistant will use the new values when started back up.
 
 It shouldn't be using a hardcoded IP address normally, unless you manually entered an IP address when setting up that ssh remote. Using DNS is better..
 """]]
diff --git a/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment b/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
index 7fe30c6dd..e5630b331 100644
--- a/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
+++ b/doc/forum/Manual_Setup_of_a_Central_Repo/comment_1_3a163fd5629dc40423f1290a78ae1c07._comment
@@ -4,7 +4,7 @@
  subject="comment 1"
  date="2013-08-26T18:46:06Z"
  content="""
-You could certianly do that. I don't think it's the easiest way.
+You could certainly do that. I don't think it's the easiest way.
 
 Note that this is essentially a git question. It really has nothing to do with git-annex, unless you want to use the git-annex assistant, which can sync a repository over XMPP without needing a central git repository at all.
 
diff --git a/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
index 2cc0c9296..dccd1d8d5 100644
--- a/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
+++ b/doc/forum/Syncronisation_of_syncronisation_between_3_repositories__63__/comment_1_ca5192a26950627a1c2efcb55d6d2fa3._comment
@@ -6,5 +6,5 @@
  content="""
 git-annex does not currently prevent multiple uploads of the same file to a rsync special remote. It is able to guard against this when uploading to a git remote, since then the remote runs git-annex-shell, which can detect when an upload is already running. You might want to convert your rsync remote to a git remote.
 
-I hope that rsyncing the same file twice at the same time is safe, but it's certianly excessively expensive.
+I hope that rsyncing the same file twice at the same time is safe, but it's certainly excessively expensive.
 """]]
diff --git a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
index d2330e336..0b3cb22c1 100644
--- a/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
+++ b/doc/forum/XBMC__44___NFS___38___git-annex_/comment_2_d8ed4dd51d3050db691a8abdec24cd42._comment
@@ -6,5 +6,5 @@
  content="""
 The default git-annex backend for over a year now is SHA256E, which includes the filename extension in the key to deal with programs that rely on them. If you're not using that backend, you can `git annex migrate` to it.
 
-Or you can turn on direct mode, which will certianly solve the problem.
+Or you can turn on direct mode, which will certainly solve the problem.
 """]]
diff --git a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
index 84fe6ef0d..c41fe492f 100644
--- a/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
+++ b/doc/forum/git-annex_assistant_with_2_dedicated_servers/comment_7_ace3dc7c60c710a04b0a587206b341c4._comment
@@ -4,5 +4,5 @@
  subject="comment 7"
  date="2013-11-16T23:04:29Z"
  content="""
-In your situation, you do not have or need a repository whose only job is to transfer files between two other client repositories. So the right choice for your repositories is client -- or something else possibly -- but almost certianly not transfer.
+In your situation, you do not have or need a repository whose only job is to transfer files between two other client repositories. So the right choice for your repositories is client -- or something else possibly -- but almost certainly not transfer.
 """]]
diff --git a/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment b/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
index b9c9d7e45..e03ec333a 100644
--- a/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
+++ b/doc/forum/not_getting_file_contents/comment_1_4a0f7f4de9c9bc4d13db033cb75d20af._comment
@@ -4,7 +4,7 @@
  subject="comment 1"
  date="2013-07-11T16:06:59Z"
  content="""
-That certianly shouldn't be happening! 
+That certainly shouldn't be happening! 
 
 Are these computers syncing via local pairing, or are you using a transfer remote, and if so, which one?
 """]]
diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment b/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
index 7791950f6..aab0ec17f 100644
--- a/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
+++ b/doc/forum/performance_and_multiple_replication_problems/comment_1_a2cdf1a4840f099f6bc941fd8de966c7._comment
@@ -12,5 +12,5 @@ It would be possible to disable that scan, but at the expense of not being able
 
 I don't quite understand what you mean with problem #2. If files were repeatedly being uploaded or downloaded, that have already been sent, that would be a bug. Please file a bug report with full debug logs if that is the case.
 
-Which topology is best? I think the best way is to start with the one you like, and if it doesn't work well, add more links between repositories. A star topology will certianly work ok. A mesh can work ok but can be hard to maintain.
+Which topology is best? I think the best way is to start with the one you like, and if it doesn't work well, add more links between repositories. A star topology will certainly work ok. A mesh can work ok but can be hard to maintain.
 """]]
diff --git a/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment b/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
index d33a296ca..67953860a 100644
--- a/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
+++ b/doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment
@@ -4,7 +4,7 @@
  subject="comment 8"
  date="2011-12-19T18:29:01Z"
  content="""
-I don't mind changing the behavior of git-annex sync, certianly..
+I don't mind changing the behavior of git-annex sync, certainly..
 
 Looking thru git's documentation, I found some existing configuration that could be reused following your idea.
 There is a remote.name.skipDefaultUpdate and a remote.name.skipFetchAll. Though both have to do with fetches, not pushes.
diff --git a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
index 5a6f0e5d0..d3fe6ef4c 100644
--- a/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
+++ b/doc/forum/speed_up_assistant_startup_on_large_repositories/comment_3_be6c4fe5a0c745688438b716973791cc._comment
@@ -6,7 +6,7 @@
  content="""
 That's right.
 
-15 minutes is certianly a very long time.
+15 minutes is certainly a very long time.
 
 Is this on a slow spinning disk? USB disk?
 """]]
diff --git a/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment b/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
index dbb0433f7..290da58f8 100644
--- a/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
+++ b/doc/install/OSX/comment_32_a46d8e3e7795b9afb1e1c2be943d12af._comment
@@ -4,7 +4,7 @@
  subject="comment 32"
  date="2013-10-21T22:47:14Z"
  content="""
-You probably need to install libdbus dev stuff, and then the haskell dbus library. But it's certianly going to need code changes to make git-annex use dbus in any way on OSX, assuming there are even useful dbus events generated for network connections and drives being mounted on OSX.
+You probably need to install libdbus dev stuff, and then the haskell dbus library. But it's certainly going to need code changes to make git-annex use dbus in any way on OSX, assuming there are even useful dbus events generated for network connections and drives being mounted on OSX.
 
 It was saying \"gcrypt\" when it meant \"git-remote-gcrypt\".
 """]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
index 15f807616..24e5f5b83 100644
--- a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_9_3784e0c828cd60b6a9075c2d32d070cc._comment
@@ -8,7 +8,7 @@
 
 Then you would need to decrypt the repository in order get the key you need to decrypt the repository. The impossibility of this design is why I didn't do that!
 
-It would certianly be possible to store a non-encrypted gpg key alongside the repsitory encrypted with it, but then you have to rely on a passphrase for all your security.
+It would certainly be possible to store a non-encrypted gpg key alongside the repsitory encrypted with it, but then you have to rely on a passphrase for all your security.
 
 You should file a bug report for the bug you saw..
 """]]
diff --git a/doc/todo/checksum_verification_on_transfer.mdwn b/doc/todo/checksum_verification_on_transfer.mdwn
index e87907d56..c9d505aec 100644
--- a/doc/todo/checksum_verification_on_transfer.mdwn
+++ b/doc/todo/checksum_verification_on_transfer.mdwn
@@ -1,6 +1,6 @@
 Since most file transfers, particularly to/from encrypted special remotes involve git-annex streaming through the contents of the file anyway, it should be possible to add a verification of the checksum nearly for free. The main thing needed is probably a faster haskell checksum library than Data.Digest.Pure.Sha, which is probably slow enough to be annoying.
 
-I have not verified if an upload could be aborted before sending the data to the remote if a checksum failure is detected. It may be dependent on the individual special remote implementations. Some probably stream the encrypted data directly out the wire, while others need to set up a temp file to run a command on. It would certianly be possible to at least make the upload abort and fail if a bad checksum was detected.
+I have not verified if an upload could be aborted before sending the data to the remote if a checksum failure is detected. It may be dependent on the individual special remote implementations. Some probably stream the encrypted data directly out the wire, while others need to set up a temp file to run a command on. It would certainly be possible to at least make the upload abort and fail if a bad checksum was detected.
 
 Doing the same for downloads is less useful, because the data is there locally to be fscked. The real advantage would be doing the check for uploads, to ensure that hard-to-detect corrupted files don't reach special remotes.
 
diff --git a/doc/todo/special_remote_for_amazon_glacier.mdwn b/doc/todo/special_remote_for_amazon_glacier.mdwn
index 0fa77b527..9b8b9d74e 100644
--- a/doc/todo/special_remote_for_amazon_glacier.mdwn
+++ b/doc/todo/special_remote_for_amazon_glacier.mdwn
@@ -3,7 +3,7 @@ long-term archival.
 
 The main difficulty is that glacier is organized into vaults, and accessing
 a file in a vault takes ~4 hours. A naive implementation would make `git
-annex get` wait for 4 hours, which is certianly not reasonable.
+annex get` wait for 4 hours, which is certainly not reasonable.
 
 One approach I am pondering is to make each glacier vault a separate
 special remote. You could then request git-annex to spin up a remote, and
diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
index 6c4d579c1..484db1e81 100644
--- a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
+++ b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_7_15bf62e46db4b84ed3156f550f03de42._comment
@@ -6,7 +6,7 @@
  content="""
 A less round-about method would be to have the webapp listen for links dropped into its page. You could then have the webapp open in a tab, and just drag urls there to add them to the annex.
 
-I'm not sure if it's possible to intercept drags into a tab. Default browser behavior is certianly to redirect the tab to the url dropped into it.
+I'm not sure if it's possible to intercept drags into a tab. Default browser behavior is certainly to redirect the tab to the url dropped into it.
 
 If someone finds out how to do this, I will build it.
 """]]
diff --git a/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment b/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment
index 29eb11622..2e12d86d4 100644
--- a/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment
+++ b/doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment
@@ -4,7 +4,7 @@
  subject="comment 2"
  date="2012-04-29T02:39:20Z"
  content="""
-The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certianly be possible to store the symmetric cipher unencrypted in the git repo. 
+The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certainly be possible to store the symmetric cipher unencrypted in the git repo. 
 
 I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up.
 """]]