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

4 files changed, 4 insertions, 4 deletions

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