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

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.
 """]]

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..
 """]]

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.
 

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.
 """]]

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.
 """]]

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.
 """]]

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?
 """]]

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.
 """]]

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.

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?
 """]]