correct spelling mistakes

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.)
 ```
 

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

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.

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

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.)
 $
 

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.)
 
 

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

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

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

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.

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.
 

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

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):