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

23 files changed, 23 insertions, 23 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.
 """]]