correct spelling mistakes

52 files changed, 69 insertions, 69 deletions

diff --git a/Annex/Branch.hs b/Annex/Branch.hs
index 9d963f98b..af29b02b0 100644
--- a/Annex/Branch.hs
+++ b/Annex/Branch.hs
@@ -574,7 +574,7 @@ checkBranchDifferences ref = do
 		<$> catFile ref differenceLog
 	mydiffs <- annexDifferences <$> Annex.getGitConfig
 	when (theirdiffs /= mydiffs) $
-		giveup "Remote repository is tuned in incompatable way; cannot be merged with local repository."
+		giveup "Remote repository is tuned in incompatible way; cannot be merged with local repository."
 
 ignoreRefs :: [Git.Sha] -> Annex ()
 ignoreRefs rs = do
diff --git a/Annex/Init.hs b/Annex/Init.hs
index 8a208fe2b..74274ad7f 100644
--- a/Annex/Init.hs
+++ b/Annex/Init.hs
@@ -119,7 +119,7 @@ uninitialize = do
 
 {- Will automatically initialize if there is already a git-annex
  - branch from somewhere. Otherwise, require a manual init
- - to avoid git-annex accidentially being run in git
+ - to avoid git-annex accidentally being run in git
  - repos that did not intend to use it.
  -
  - Checks repository version and handles upgrades too.
diff --git a/Annex/Perms.hs b/Annex/Perms.hs
index 644402587..80eb71f37 100644
--- a/Annex/Perms.hs
+++ b/Annex/Perms.hs
@@ -148,7 +148,7 @@ thawPerms a = ifM crippledFileSystem
 	)
 
 {- Blocks writing to the directory an annexed file is in, to prevent the
- - file accidentially being deleted. However, if core.sharedRepository
+ - file accidentally being deleted. However, if core.sharedRepository
  - is set, this is not done, since the group must be allowed to delete the
  - file.
  -}
diff --git a/CHANGELOG b/CHANGELOG
index 9a5d181d6..20014ea7d 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1048,7 +1048,7 @@ git-annex (5.20150731) unstable; urgency=medium
   * webapp: Support enabling known gitlab.com remotes.
   * Fix rsync special remote to work when -Jn is used for concurrent
     uploads.
-  * The last release accidentially removed a number of options from the
+  * The last release accidentally removed a number of options from the
     copy command. (-J, file matching options, etc). These have been added
     back.
   * init: Detect when the filesystem is crippled such that it ignores
@@ -1258,7 +1258,7 @@ git-annex (5.20150508) unstable; urgency=medium
     (endpoint, port, storage class)
   * S3: Let git annex enableremote be used, without trying to recreate
     a bucket that should already exist.
-  * S3: Fix incompatability with bucket names used by hS3; the aws library
+  * S3: Fix incompatibility with bucket names used by hS3; the aws library
     cannot handle upper-case bucket names. git-annex now converts them to
     lower case automatically.
   * import: Check for gitignored files before moving them into the tree.
@@ -1655,7 +1655,7 @@ git-annex (5.20141125) unstable; urgency=medium
 
   * Remove fixup code for bad bare repositories created by
     versions 5.20131118 through 5.20131127. That fixup code would
-    accidentially fire when --git-dir was incorrectly
+    accidentally fire when --git-dir was incorrectly
     pointed at the working tree of a git-annex repository,
     possibly resulting in data loss. Closes: #768093
   * Windows: Fix crash when user.name is not set in git config.
@@ -3441,7 +3441,7 @@ git-annex (3.20130124) unstable; urgency=low
   * webapp: Has a page to view the log, accessed from the control menu.
   * webapp: Fix crash adding removable drive that has an annex directory
     in it that is not a git repository.
-  * Deal with incompatability in gpg2, which caused prompts for encryption
+  * Deal with incompatibility in gpg2, which caused prompts for encryption
     passphrases rather than using the supplied --passphrase-fd.
   * bugfix: Union merges involving two or more repositories could sometimes
     result in data from one repository getting lost. This could result
@@ -3541,7 +3541,7 @@ git-annex (3.20121211) unstable; urgency=low
     associated with a file.
   * webapp: S3 and Glacier forms now have a select list of all
     currently-supported AWS regions.
-  * webdav: Avoid trying to set props, avoiding incompatability with
+  * webdav: Avoid trying to set props, avoiding incompatibility with
     livedrive.com. Needs DAV version 0.3.
   * webapp: Prettify error display.
   * webapp: Fix bad interaction between required fields and modals.
@@ -4970,7 +4970,7 @@ git-annex (0.04) unstable; urgency=low
   * Note that git-annex 0.04 cannot transfer content from old repositories
     that have not yet been upgraded.
   * Annexed file contents are now made unwritable and put in unwriteable
-    directories, to avoid them accidentially being removed or modified.
+    directories, to avoid them accidentally being removed or modified.
     (Thanks Josh Triplett for the idea.)
   * Add build dep on libghc6-testpack-dev. Closes: #603016
   * Avoid using runghc to run test suite as it is not available on all
diff --git a/Command/Direct.hs b/Command/Direct.hs
index 06adf0e05..817cedd53 100644
--- a/Command/Direct.hs
+++ b/Command/Direct.hs
@@ -26,7 +26,7 @@ seek = withNothing start
 start :: CommandStart
 start = ifM versionSupportsDirectMode
 	( ifM isDirect ( stop , next perform )
-	, giveup "Direct mode is not suppported by this repository version. Use git-annex unlock instead."
+	, giveup "Direct mode is not supported by this repository version. Use git-annex unlock instead."
 	)
 
 perform :: CommandPerform
diff --git a/Command/Unannex.hs b/Command/Unannex.hs
index e744b51a8..e3e8d51ab 100644
--- a/Command/Unannex.hs
+++ b/Command/Unannex.hs
@@ -26,7 +26,7 @@ import Git.FilePath
 cmd :: Command
 cmd = withGlobalOptions annexedMatchingOptions $
 	command "unannex" SectionUtility
-		"undo accidential add command"
+		"undo accidental add command"
 		paramPaths (withParams seek)
 
 seek :: CmdParams -> CommandSeek
diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
index 029ac4b09..b72a60efa 100644
--- a/Remote/Helper/Encryptable.hs
+++ b/Remote/Helper/Encryptable.hs
@@ -70,7 +70,7 @@ encryptionSetup c gc = do
 			(map ("encryption=" ++)
 				["none","shared","hybrid","pubkey", "sharedpubkey"])
 			++ "."
-	key = fromMaybe (giveup "Specifiy keyid=...") $ M.lookup "keyid" c
+	key = fromMaybe (giveup "Specify keyid=...") $ M.lookup "keyid" c
 	newkeys = maybe [] (\k -> [(True,k)]) (M.lookup "keyid+" c) ++
 		maybe [] (\k -> [(False,k)]) (M.lookup "keyid-" c)
 	cannotchange = giveup "Cannot set encryption type of existing remotes."
diff --git a/Test.hs b/Test.hs
index 7174d6523..cb3df90a0 100644
--- a/Test.hs
+++ b/Test.hs
@@ -122,7 +122,7 @@ runner = Just $ \opts -> isolateGitConfig $ do
 		Just act -> ifM act
 			( exitSuccess
 			, do
-				putStrLn "  (This could be due to a bug in git-annex, or an incompatability"
+				putStrLn "  (This could be due to a bug in git-annex, or an incompatibility"
 				putStrLn "   with utilities, such as git, installed on this system.)"
 				exitFailure
 			)
@@ -452,7 +452,7 @@ test_drop_untrustedremote = intmpclonerepo $ do
 	git_annex "untrust" ["origin"] @? "untrust of origin failed"
 	git_annex "get" [annexedfile] @? "get failed"
 	annexed_present annexedfile
-	not <$> git_annex "drop" [annexedfile] @? "drop wrongly suceeded with only an untrusted copy of the file"
+	not <$> git_annex "drop" [annexedfile] @? "drop wrongly succeeded with only an untrusted copy of the file"
 	annexed_present annexedfile
 	inmainrepo $ annexed_present annexedfile
 
diff --git a/Utility/LockFile/Windows.hs b/Utility/LockFile/Windows.hs
index d05a44747..e76157354 100644
--- a/Utility/LockFile/Windows.hs
+++ b/Utility/LockFile/Windows.hs
@@ -38,7 +38,7 @@ lockExclusive = openLock fILE_SHARE_NONE
 {- Windows considers just opening a file enough to lock it. This will
  - create the LockFile if it does not already exist.
  -
- - Will fail if the file is already open with an incompatable ShareMode.
+ - Will fail if the file is already open with an incompatible ShareMode.
  - Note that this may happen if an unrelated process, such as a virus
  - scanner, even looks at the file. See http://support.microsoft.com/kb/316609
  -
diff --git a/Utility/PartialPrelude.hs b/Utility/PartialPrelude.hs
index 557955633..47e98318a 100644
--- a/Utility/PartialPrelude.hs
+++ b/Utility/PartialPrelude.hs
@@ -2,7 +2,7 @@
  - bugs.
  -
  - This exports functions that conflict with the prelude, which avoids
- - them being accidentially used.
+ - them being accidentally used.
  -}
 
 {-# OPTIONS_GHC -fno-warn-tabs #-}
diff --git a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn
index 17b66bbab..fcd32f9dc 100644
--- a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn
+++ b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn
@@ -33,7 +33,7 @@ FAIL (0.29s)
       addurl failed on file:///private/var/folders/4j/br7bdhjx4b384_snb2087gt00000gn/T/nix-build-git-annex-5.20151116.drv-0/git-annex-5.20151116/.t/tmprepo0/myurl
 
 2 out of 150 tests failed (126.13s)
-  (This could be due to a bug in git-annex, or an incompatability
+  (This could be due to a bug in git-annex, or an incompatibility
    with utilities, such as git, installed on this system.)
 ```
 
diff --git a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
index 9532d0fd0..b0bf84a60 100644
--- a/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
+++ b/doc/bugs/Handling_of_files_inside_and_outside_archive_directory_at_the_same_time.mdwn
@@ -1,6 +1,6 @@
 Hi,
 
-some time ago, I accidentially copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really suprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it.
+some time ago, I accidentally copied some files from the archive to the non-archive part of my (indirect, type 'client') repository (instead of moving), with the effect that assistant always kept downloading and afterwards immediately dropping the files. Now this was not really surprising once I found the duplicate folder, but maybe git annex could detect this case and refuse to run in circles or at least complain about it.
 
 Best
 Karsten
diff --git a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment
index 43b37c020..90491e562 100644
--- a/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment
+++ b/doc/bugs/Move_out_of_shared_repository_as___34__maintenance_user__34___gives_permission_denied_for_files_edited_by_others/comment_1_5c06ab75371237a263c836da45106707._comment
@@ -18,10 +18,10 @@ content of objects when in sharedRepository mode, like it normally does.
 
 Since that's a belt and suspenders protection, and since the object
 directory permissions weakening already lost a similar protection against
-accidential deletion of object files, shrug, I guess we'll do that.
+accidental deletion of object files, shrug, I guess we'll do that.
 
 I do feel that sharedRepository mode rarely ever makes sense to use. It's
-very fiddely to get the permissions set up right and keep them right, and
+very fiddly to get the permissions set up right and keep them right, and
 there are much better ways to share a centralized repo between users, eg
 use gitolite or a dedicated account that's locked down to only let
 git/git-annex commands be run.
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
index 83a01311c..4dfe0f460 100644
--- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
+++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds__58___no_longer_usable_on_CentOS_6.5/comment_4_641389c7c52fa4f624ae74b5d32a6b1c._comment
@@ -11,8 +11,8 @@ building all libraries again. So, it would be a lot of CPU on an ongoing basis,
 or a source of unfixed security bugs. 
 
 And, I think it would not be entirely non-fragile. It's not exactly unheard
-of for a new version of a haskell library to accidentially break
-compatability with the old version of ghc which is generally unused in the
+of for a new version of a haskell library to accidentally break
+compatibility with the old version of ghc which is generally unused in the
 haskell community outside of debian stable. Or, to need a newer version of
 some C library headers than is in stable, or ...
 """]]
diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
index d7a635d3c..11f4a9a3e 100644
--- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
+++ b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
@@ -70,7 +70,7 @@ OK (0.78s)
 [Removed 1667 lines]
 
 3 out of 269 tests failed (640.58s)
-  (This could be due to a bug in git-annex, or an incompatability
+  (This could be due to a bug in git-annex, or an incompatibility
    with utilities, such as git, installed on this system.)
 $
 
diff --git a/doc/bugs/Windows_build_test_failures.mdwn b/doc/bugs/Windows_build_test_failures.mdwn
index ac4dce13c..c276c294e 100644
--- a/doc/bugs/Windows_build_test_failures.mdwn
+++ b/doc/bugs/Windows_build_test_failures.mdwn
@@ -1222,7 +1222,7 @@ crypto
 preferred content
 ----------------------------------------------------------------------
 Some tests failed!
-  (This could be due to a bug in git-annex, or an incompatability
+  (This could be due to a bug in git-annex, or an incompatibility
    with utilities, such as git, installed on this system.)
 
 
diff --git a/doc/bugs/addurl_unittest_failing_under_windows.mdwn b/doc/bugs/addurl_unittest_failing_under_windows.mdwn
index f1cc7a3a7..8458ed83b 100644
--- a/doc/bugs/addurl_unittest_failing_under_windows.mdwn
+++ b/doc/bugs/addurl_unittest_failing_under_windows.mdwn
@@ -47,7 +47,7 @@ FAIL (7.16s)
       addurl failed on file:///Users/born/.t/tmprepo0/myurl
 
 1 out of 1 tests failed (28.13s)
-  (This could be due to a bug in git-annex, or an incompatability
+  (This could be due to a bug in git-annex, or an incompatibility
    with utilities, such as git, installed on this system.)
 """]]
 
diff --git a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn
index 0d7804a43..cb0ed5edf 100644
--- a/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn
+++ b/doc/bugs/after_git_annex_add_and_commit__44___git_annex_fsck_fails__58___no_known_copies.mdwn
@@ -10,7 +10,7 @@ I use git v1.9.1 on Ubuntu 14.04 LTS, and git-annex version: 5.20150406-gb2814bc
 
 OK, in all honesty, I did a 'git annex sync' between the 'add' and the 'commit' above. But I synced with a clone of the repository that I keep on an external drive, which is less updated than my laptop. It is less updated because I always add content on my laptop and then sync/get from the external disk. So the sync did no harm, apparently.
 
-> Since this seems to be only a problem with messaging about accidentially
+> Since this seems to be only a problem with messaging about accidentally
 > marked dead repositories, I've made fsck mention when a file is only
 > located in a dead repo, and I've made info tell when it's run in a
 > supposedly-dead repo. [[done]] --[[Joey]]
diff --git a/doc/bugs/direct_mode_merge_interrupt.mdwn b/doc/bugs/direct_mode_merge_interrupt.mdwn
index 5c26e1773..f6bb795b6 100644
--- a/doc/bugs/direct_mode_merge_interrupt.mdwn
+++ b/doc/bugs/direct_mode_merge_interrupt.mdwn
@@ -20,7 +20,7 @@ update the whole work tree, and only after it's updated should it update
 the index and the current branch to reflect the merge.  
 
 This way, if the merge is interrupted, the work tree may have uncommitted
-changed -- but it's fine if they get accidentially committed, since when
+changed -- but it's fine if they get accidentally committed, since when
 the merge is re-done, those changes will by the same ones made by the
 merge. (I assume this is how `git merge` normally works.) --[[Joey]]
 
diff --git a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment
index d97f66d8d..b48cfbca3 100644
--- a/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment
+++ b/doc/bugs/git-annex_can__39__t_find_gpg_if_it__39__s_named_gpg2/comment_1_b17661b0dbec3a72b2fd9608f0ba6823._comment
@@ -4,7 +4,7 @@
  date="2015-09-09T21:12:01Z"
  content="""
 git-annex should work ok with gpg version 2; there was one minor
-incompatability vs gpg version 1, but it was ironed out in 2013.
+incompatibility vs gpg version 1, but it was ironed out in 2013.
 
 If you build it from source, and have only gpg2 in PATH, and not gpg, it
 will build a git-annex that runs gpg2.
diff --git a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn
index 57c1e1d25..c660f065b 100644
--- a/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn
+++ b/doc/bugs/linux_standalone_git_annex_won__39__t_work_in_a_directory_whose_path_contains___58___or___59__.mdwn
@@ -1,6 +1,6 @@
 ### Please describe the problem.
 
-The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriatly.  glibc's parsing of library-path treats : and ; as seperaters and has no quoting syntax for those characters.  Also path items have to be absolute paths so you can't avoid having the whole path.
+The shim for the standalone version of git annex invokes the dynamic linker with --library-path set appropriately.  glibc's parsing of library-path treats : and ; as separators and has no quoting syntax for those characters.  Also path items have to be absolute paths so you can't avoid having the whole path.
 
 As a result if you install the standalone version in a directory whose path includes either of those characters it will produce a library-path that's interpreted incorrectly leading to it looking for the libraries in the wrong place and potentially eventually using the system's installed versions if they are available.
 
@@ -18,7 +18,7 @@ This bug applies to any version.  with a ':' it will probably occur on any unix,
 
 ### Please provide any additional information below.
 
-This bug can't be fixed.  It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels.  The worst case would be incompatable libraries on the system install which could lead to data corruption.
+This bug can't be fixed.  It's unlikely to trip people up but might with a bad combination of label-based drive mounting and odd drive labels.  The worst case would be incompatible libraries on the system install which could lead to data corruption.
 
 I recommend that the git annex shim should check for ':' or ';' in the path and exit non-zero if they are found.
 
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
index ea9db7bc6..672a3a560 100644
--- a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
+++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error_/comment_1_464d733de18f6ca438ebd84e88b8cee2._comment
@@ -8,7 +8,7 @@ that the other side fails to deal with. We can see in your log that the
 two rsync are communicating successfully over the ssh connection
 at first.
 
-This could be something not clean about your ssh connection, or some incompatability
+This could be something not clean about your ssh connection, or some incompatibility
 in the versions of rsync or git-annex between the client and the server.
 It probably wouldn't hurt to make sure client and server have the same rsync
 version, and perhaps upgrade them both to the newest git-annex in case this
diff --git a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
index ffad58ec8..065ff3ce0 100644
--- a/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
+++ b/doc/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index.mdwn
@@ -1,8 +1,8 @@
 ### Please describe the problem.
 
-I understand that `git annex unannex` is essentially there for undoing an accidential `git annex add`. Unfortunately it doesn't do that.
+I understand that `git annex unannex` is essentially there for undoing an accidental `git annex add`. Unfortunately it doesn't do that.
 
-If I have uncommited changes, which is the case after a `git annex add`, it tells me:
+If I have uncommitted changes, which is the case after a `git annex add`, it tells me:
 
     git-annex: Cannot proceed with uncommitted changes staged in the index. Recommend you: git commit
     CallStack (from HasCallStack):
diff --git a/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
index 78d263b6d..0dd600cc8 100644
--- a/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
+++ b/doc/design/assistant/blog/day_126__mr_watson_come_here.mdwn
@@ -13,7 +13,7 @@ at debugging output to find:
    messages.
 2. The git-receive-pack side waited on the wrong thread, so didn't
    notice when the program was done.
-3. I accidentially used the wrong attribute name when sending a ReceivePackDone
+3. I accidentally used the wrong attribute name when sending a ReceivePackDone
    message.
 
 But all in all, it just worked.
diff --git a/doc/design/assistant/blog/day_172__short_day.mdwn b/doc/design/assistant/blog/day_172__short_day.mdwn
index 031f90e0f..80a32d87e 100644
--- a/doc/design/assistant/blog/day_172__short_day.mdwn
+++ b/doc/design/assistant/blog/day_172__short_day.mdwn
@@ -1,5 +1,5 @@
 Only one bug fix today, but it was a doozie. It seems that gpg2 has an
-incompatability with the gpg 1.x that git-annex was written for, that
+incompatibility with the gpg 1.x that git-annex was written for, that
 causes large numbers of excess passphrase prompts, when it's supposed to be
 using a remote's symmetric encryption key. Adding the --batch parameter
 fixed this.
diff --git a/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
index 57a601530..455029a41 100644
--- a/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
+++ b/doc/design/assistant/blog/day_195__real_android_app/comment_13_4f6bc0680f2debd638933968a26975e0._comment
@@ -6,5 +6,5 @@
  content="""
 @Karsten does KBOX work on this version of Android? <http://kevinboone.net/Term-debug.apk>
 
-It may well be that this is just too old and incompatable for the terminal to work.
+It may well be that this is just too old and incompatible for the terminal to work.
 """]]
diff --git a/doc/design/assistant/upgrading.mdwn b/doc/design/assistant/upgrading.mdwn
index b1d658c8b..1395d0cd8 100644
--- a/doc/design/assistant/upgrading.mdwn
+++ b/doc/design/assistant/upgrading.mdwn
@@ -21,7 +21,7 @@ restarts itself.
 
 To clean up the old installation, a git-annex.MANIFEST file is looked for
 in it, and the files listed, as well as empty directories, are deleted.
-I don't want to accidentially delete something I didn't ship!
+I don't want to accidentally delete something I didn't ship!
 
 ## restart on upgrade
 
diff --git a/doc/design/caching_database.mdwn b/doc/design/caching_database.mdwn
index 87efd9810..c27c9557c 100644
--- a/doc/design/caching_database.mdwn
+++ b/doc/design/caching_database.mdwn
@@ -87,7 +87,7 @@ MVars.)
 
 (Note that if the database is a cache, there is no need to perform migrations
 when querying it. My benchmarks skip `runMigration`. Instead, if the query
-fails, the database doesn't exist, or uses an incompatable schema, and the
+fails, the database doesn't exist, or uses an incompatible schema, and the
 cache can be rebuilt then. This avoids the problem that persistent's migrations
 can sometimes fail.)
 
diff --git a/doc/devblog/day_109__elimintating_absNormPath.mdwn b/doc/devblog/day_109__elimintating_absNormPath.mdwn
index a15cb7f09..8381f2956 100644
--- a/doc/devblog/day_109__elimintating_absNormPath.mdwn
+++ b/doc/devblog/day_109__elimintating_absNormPath.mdwn
@@ -11,7 +11,7 @@ That fixed one last Windows bug that was disabled in the test suite:
 `git annex add ..\subdir\file` will now work.
 
 I am re-installing the Android autobuilder for 2 reasons: I noticed I had
-accidentially lost a patch to make a library use the Android SSL cert directory,
+accidentally lost a patch to make a library use the Android SSL cert directory,
 and also a new version of GHC is very near to release and so it makes sense
 to update.
 
diff --git a/doc/devblog/day_248__workload_tuning.mdwn b/doc/devblog/day_248__workload_tuning.mdwn
index d1fee2926..d0677fc60 100644
--- a/doc/devblog/day_248__workload_tuning.mdwn
+++ b/doc/devblog/day_248__workload_tuning.mdwn
@@ -8,7 +8,7 @@ Today I put together a lot of things I've been thinking about:
   git-annex user to upgrade their repository, and would be very painful.
   It's hard to imagine a change that is worth that amount of pain.
 * There are other changes some would like to see (like lower-case object
-  hash directory names) that are certianly not enough to warrant a flag
+  hash directory names) that are certainly not enough to warrant a flag
   day repo format upgrade.
 * It would be nice to let people who want to have some flexibility to play
   around with changes, in their own repos, as long as they don't a)
@@ -32,7 +32,7 @@ The main limitations are:
 
 I built all the infrastructure for this today. Basically, the git-annex
 branch gets a record of all tunings that have been applied, and they're
-automatically propigated to new clones of a repository.
+automatically propagated to new clones of a repository.
 
 And I implemented the first tunable setting:
 
@@ -40,10 +40,10 @@ And I implemented the first tunable setting:
 
 This is definitely an experimental feature for now.
 `git-annex merge` and similar commands will detect attempts to merge
-between incompatably tuned repositories, and error out. But, there are a
+between incompatibly tuned repositories, and error out. But, there are a
 lot of ways to shoot yourself in the foot if you use this feature:
 
-* Nothing stops `git merge` from merging two incompatable repositories.
+* Nothing stops `git merge` from merging two incompatible repositories.
 * Nothing stops any version of git-annex older from today from merging
   either.
 
diff --git a/doc/devblog/day_280__slow_week.mdwn b/doc/devblog/day_280__slow_week.mdwn
index 0c49b33bc..ed0dce49d 100644
--- a/doc/devblog/day_280__slow_week.mdwn
+++ b/doc/devblog/day_280__slow_week.mdwn
@@ -2,7 +2,7 @@ Reduced activity this week (didn't work on the assistant after all),
 but several things got done:
 
 Monday: Fixed `fsck --fast --from remote` to not fail when the remote
-didn't support fast copy mode. And dealt with an incompatability in S3 bucket
+didn't support fast copy mode. And dealt with an incompatibility in S3 bucket
 names; the old hS3 library supported upper-case bucket names but the new
 one needs them all in lower case.
 
diff --git a/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
index 58755de91..d55823f75 100644
--- a/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
+++ b/doc/devblog/day_281__catching_up__and_arm_autobuilder_needed.mdwn
@@ -14,8 +14,8 @@ and so lets a lot of queries be done much faster. The implementation
 should make it easy to add --batch to more plumbing commands as needed,
 and could probably extend to non-plumbing commands too.
 
-Today: The first 5 hours involved an incompatable mess of ssh and rsync
-versions on Windows. A gordian knot of brokenness and depedency hell.
+Today: The first 5 hours involved an incompatible mess of ssh and rsync
+versions on Windows. A Gordian knot of brokenness and dependency hell.
 I finally found a solution which involves downgrading the cygwin rsync
 to an older version, and using msysgit's ssh rather than cygwin's.
 
diff --git a/doc/devblog/day_307__two_release_week.mdwn b/doc/devblog/day_307__two_release_week.mdwn
index 32202906f..0b8a1595e 100644
--- a/doc/devblog/day_307__two_release_week.mdwn
+++ b/doc/devblog/day_307__two_release_week.mdwn
@@ -1,5 +1,5 @@
 Made a release this morning, mostly because the release earlier this week
-turns out to have accidentially removed several options from `git annex copy`.
+turns out to have accidentally removed several options from `git annex copy`.
 
 Spent some time this afternoon improving how git-annex shuts down when
 --time-limit is used. This used to be a quick and dirty shutdown, similar
diff --git a/doc/devblog/day_35__anacron_and_bugfixing.mdwn b/doc/devblog/day_35__anacron_and_bugfixing.mdwn
index af021d576..dc8fbb628 100644
--- a/doc/devblog/day_35__anacron_and_bugfixing.mdwn
+++ b/doc/devblog/day_35__anacron_and_bugfixing.mdwn
@@ -3,13 +3,13 @@ one more feature to it today: Full anacron style scheduling. So a fsck can
 be scheduled to run once per week, or month, or year, and it'll run the
 fsck the next time it's available after that much time has passed. The nice
 thing about this is I didn't have to change Cronner *at all* to add this,
-just improved the Recurrance data type and the code that calculates when
+just improved the Recurrence data type and the code that calculates when
 to run events.
 
 Rest of the day I've been catching up on some bug reports. The main bug I
 fixed caused git-annex on Android to hang when adding files. This turns out
 to be because it's using a new (unreleased) version of git, and
-`git check-attr -z` output format has changed in an incompatable way.
+`git check-attr -z` output format has changed in an incompatible way.
 
 I am currently 70 messages behind, which includes some ugly looking bug
 reports, so I will probably continue with this over the next couple days.
diff --git a/doc/devblog/day_387__release_day.mdwn b/doc/devblog/day_387__release_day.mdwn
index 0a36a61da..c7a294aed 100644
--- a/doc/devblog/day_387__release_day.mdwn
+++ b/doc/devblog/day_387__release_day.mdwn
@@ -1,6 +1,6 @@
 git-annex 6.20160419 has a rare security fix.
 A [bug](http://git-annex.branchable.com/bugs/External_special_remote_broken__63__/) made encrypted special
-remotes that are configured to use chunks accidentially expose the checksums
+remotes that are configured to use chunks accidentally expose the checksums
 of content that is uploaded to the remote. Such information is supposed to
 be hidden from the remote's view by the encryption. The same bug also made
 resuming interrupted uploads to such remotes start over from the beginning.
diff --git a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
index f345e64b7..9c20baad7 100644
--- a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
+++ b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
@@ -4,7 +4,7 @@
  subject="comment 1"
  date="2016-04-29T10:26:22Z"
  content="""
-> A bug made encrypted special remotes that are configured to use chunks accidentially expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
+> A bug made encrypted special remotes that are configured to use chunks accidentally expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
 
 What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a `git annex sync` enough?
 
diff --git a/doc/devblog/day_396__misc_fixes.mdwn b/doc/devblog/day_396__misc_fixes.mdwn
index ed9219adf..8f33d66ea 100644
--- a/doc/devblog/day_396__misc_fixes.mdwn
+++ b/doc/devblog/day_396__misc_fixes.mdwn
@@ -1,5 +1,5 @@
 A productive day of small fixes. Including a change to deal with an
-incompatability in git 2.9's commit.gpgsign, and couple of fixes
+incompatibility in git 2.9's commit.gpgsign, and couple of fixes
 involving gcrypt repositories.
 
 Also several improvements to cloning from repositories where an adjusted
diff --git a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
index f3a1ca577..cadf944cd 100644
--- a/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
+++ b/doc/forum/Git_Annex_Sync_Delinks_Files/comment_3_5278164dab570755ed58afe466dfad42._comment
@@ -6,7 +6,7 @@
  content="""
 \"Checking out files\" is a message printed by git (not by git-annex) when it is updating the work tree.
 
-It still seems that you have somehow committed large files directly to git. Perhaps you accidentially ran \"git add\" on a large file.
+It still seems that you have somehow committed large files directly to git. Perhaps you accidentally ran \"git add\" on a large file.
 
 git annex sync is probably merging this commit from one of your other repositories.
 """]]
diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
index 6cf5541e8..9cbe0939c 100644
--- a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
+++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository/comment_1_17db96492e6bc0e243fc7cb62565c4c4._comment
@@ -9,7 +9,7 @@ A few likely reasons:
 * If a 4th client repository had popped up. 
 * If you have configured a high number of copies, it might only be able to be met by keeping files on the transfer repository.
 * Similarly, if a repository that used to have the files has been marked as dead or deleted, more copies might be needed to make up for that.
-* For completeness, if the transfer repository accidentially had its type changed to some other kind of repository, like a full backup.
+* For completeness, if the transfer repository accidentally had its type changed to some other kind of repository, like a full backup.
 
 You can enable debugging (start with --debug or go into the webapp's preferences) and it might say a little more, but the debugging info is not very good.
 
diff --git a/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
index f762c0445..05dbbed76 100644
--- a/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
+++ b/doc/forum/How_to_overwrite_local_changes__63__/comment_1_1753d8c7a0daf04b64d639567a349190._comment
@@ -16,5 +16,5 @@ too many files to look at.
 
 Another approach is to look at the git log, find the commit that merged
 the unwanted changed (and created these variant files), and `git revert` that
-merge, and the earlier commit that was made accidentially.
+merge, and the earlier commit that was made accidentally.
 """]]
diff --git a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
index c30ad8999..46ddb5f16 100644
--- a/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
+++ b/doc/forum/Layout_mismatch_between_symlinks_and_annex_objects/comment_2_9134154ba2ef3575c39c7848136b79a9._comment
@@ -3,7 +3,7 @@
  subject="""comment 2"""
  date="2015-09-09T18:18:17Z"
  content="""
-I wish this incompatability didn't exist either, but the transition to use
+I wish this incompatibility didn't exist either, but the transition to use
 consistently 3 letter hash directories would be too much to ask of all the
 users. And there are ways to convert a bare to non-bare that don't have
 this problem, like making a clone and using `git annex move --all --from
diff --git a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
index 4b250a3e2..d0b89c59e 100644
--- a/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
+++ b/doc/forum/fatal__58___Out_of_memory__63___mmap_failed__58___No_such_file_or_directory/comment_4_cf7f5c91d3c15f72d2a714b7362c1197._comment
@@ -26,5 +26,5 @@ And here for a binary file stored in git:
 
 If you find the latter in the log, then the author and commit message of the commit adding it would be interesting.
 
-Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentially committed it directly to git.
+Hypothesis: Perhaps this repository started off on a Linux or OSX system, and you were using a git-annex older than 5.20131118, when the direct mode guard was added. You might have added this file back then and accidentally committed it directly to git.
 """]]
diff --git a/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
index 3a07bf0af..d2f3c4f73 100644
--- a/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
+++ b/doc/forum/git_annex_get_creates_a_new_uuid/comment_1_004c87183968c326058bd3159a5baa0b._comment
@@ -7,8 +7,8 @@
 From the man page:
 
 > Until a repository (**or one of its remotes**) has been initialized
-> git-annex will refuse to operate on it, to avoid accidentially
-> using it in a repository that was not intended tohave an annex.
+> git-annex will refuse to operate on it, to avoid accidentally
+> using it in a repository that was not intended to have an annex.
 
 So, yes, it assumes that if a repository has a git-annex branch already, git-annex is being used, and no explicit init is necessary. You can still run `git annex init` after the fact if you like.
 """]]
diff --git a/doc/forum/webapp_does_not_start.mdwn b/doc/forum/webapp_does_not_start.mdwn
index 3003af7d0..ad4275970 100644
--- a/doc/forum/webapp_does_not_start.mdwn
+++ b/doc/forum/webapp_does_not_start.mdwn
@@ -42,7 +42,7 @@ EDIT:
           Exception: .t/tmprepo9/.git/annex/journal: getDirectoryContents: permission denied (Access is denied.)
 
     2 out of 83 tests failed
-      (This could be due to a bug in git-annex, or an incompatability
+      (This could be due to a bug in git-annex, or an incompatibility
        with utilities, such as git, installed on this system.)
 
 
diff --git a/doc/internals/lockdown.mdwn b/doc/internals/lockdown.mdwn
index a7775cd3a..5e1160de1 100644
--- a/doc/internals/lockdown.mdwn
+++ b/doc/internals/lockdown.mdwn
@@ -1,6 +1,6 @@
 Object files stored in `.git/annex/objects` are each put in their own directory.
 This allows the write bit to be removed from both the file, and its directory,
-which prevents accidentially deleting or changing the file contents.
+which prevents accidentally deleting or changing the file contents.
 
 The reasoning for doing this follows:
 
@@ -16,7 +16,7 @@ But git-annex does not make a local copy of a file added to it, because
 the file could be very large.
 
 So, it's important for git-annex to find another way to preserve the expected
-property that once committed, you cannot accidentially lose a file.
+property that once committed, you cannot accidentally lose a file.
 The most important protection it makes is just to remove the write bit of
 the file. Thus preventing programs from modifying it.
 
diff --git a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
index 47b0aaefa..f29a2e34c 100644
--- a/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
+++ b/doc/special_remotes/S3/comment_12_59c3ecab7dbc8be53258460473cac21c._comment
@@ -4,5 +4,5 @@
  subject="comment 12"
  date="2013-05-24T15:33:12Z"
  content="""
-Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentially publishing their AWS creds to their friends, since that could cost them a lot of money.
+Ah -- No, your AWS creds are not stored. While some other special remotes, like webdav, can store all necessary credentials, it's not done for AWS. I didn't want git-annex to be responsible for someone accidentally publishing their AWS creds to their friends, since that could cost them a lot of money.
 """]]
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
index 354469118..2df15f193 100644
--- a/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt.mdwn
@@ -48,7 +48,7 @@ data out of your encrypted backup. You need to find a secure way to store a
 backup of your gpg key. Printing it out and storing it in a safe deposit box,
 for example.
 
-You can actually specifiy keyid= as many times as you like to allow any one
+You can actually specify keyid= as many times as you like to allow any one
 of a set of gpg keys to access this repository. So you could add a friend's
 key, or another gpg key you have.
 
diff --git a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment b/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment
index ca60ec5fd..0732b7dde 100644
--- a/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment
+++ b/doc/todo/Add_confirmation_dialog_to_the_restart_option/comment_1_00da59dc2d9b86a51eb462c481ab665d._comment
@@ -6,7 +6,7 @@
 Restarting the daemon should just take a second and the web browser should
 redirect to the new instance. I guess it does move away from the current
 page to the dashboard, and in a way that the back button can't undo, but I
-see no other harm in accidentially restarting the daemon.
+see no other harm in accidentally restarting the daemon.
 
 So, I think I'll just add a spacer to separate the repository part of that
 menu from the daemon part.
diff --git a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
index ba8526a34..6d4f9b026 100644
--- a/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
+++ b/doc/todo/be_able_to_specify_custom_commit_message_for_git-annex_branch_commit/comment_1_c8836a164c8c1efedd5467233237bfd0._comment
@@ -10,7 +10,7 @@ out of the user's view, because it's a complication that should not
 need to worry about.
 
 Keeping it in an env var does avoid complicating the discoverable
-interface with some parameter to specifiy the commit message. Another
+interface with some parameter to specify the commit message. Another
 way would be to make the commit message configurable in git config.
 Then it could be overridden with -c. Seems like the user of this 
 feature is likely going to also use annex.alwayscommit=false sometimes
diff --git a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment
index 8e955fd48..2907dafc3 100644
--- a/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment
+++ b/doc/todo/wishlist__58___make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment
@@ -4,7 +4,7 @@
  subject="comment 3"
  date="2012-11-04T19:58:28Z"
  content="""
-I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Or the user accidentially doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.)
+I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentally git committing a bad symlink. Or the user accidentally doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.)
 
 However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`.
 """]]
diff --git a/standalone/linux/skel/runshell b/standalone/linux/skel/runshell
index a4578eb1b..4b586d5fd 100755
--- a/standalone/linux/skel/runshell
+++ b/standalone/linux/skel/runshell
@@ -80,7 +80,7 @@ if [ -z "$GIT_ANNEX_PACKAGE_INSTALL" ]; then
 	fi
 fi
 
-# Put our binaries first, to avoid issues with out of date or incompatable
+# Put our binaries first, to avoid issues with out of date or incompatible
 # system binaries. Extra binaries come after system path.
 ORIG_PATH="$PATH"
 export ORIG_PATH
diff --git a/standalone/osx/git-annex.app/Contents/MacOS/runshell b/standalone/osx/git-annex.app/Contents/MacOS/runshell
index 17c95698c..56d8349f2 100755
--- a/standalone/osx/git-annex.app/Contents/MacOS/runshell
+++ b/standalone/osx/git-annex.app/Contents/MacOS/runshell
@@ -60,7 +60,7 @@ if [ ! -e "$HOME/.ssh/git-annex-wrapper" ]; then
 	fi
 fi
 
-# Put our binaries first, to avoid issues with out of date or incompatable
+# Put our binaries first, to avoid issues with out of date or incompatible
 # system binaries. Extra binaries come after system path.
 ORIG_PATH="$PATH"
 export ORIG_PATH