Fix compatable typo (yet to add to codespell)

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "git-sedi compatable compatible",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^

CHANGELOG

@@ -4576,7 +4576,7 @@ git-annex (5.20150508) unstable; urgency=medium
     --clean-duplicates mode, verify that enough copies of its content still
     exist.
   * Improve integration with KDE's file manager to work with dolphin
-    version 14.12.3 while still being compatable with 4.14.2.
+    version 14.12.3 while still being compatible with 4.14.2.
     Thanks, silvio.
   * assistant: Added --autostop to complement --autostart.
   * Work around wget bug #784348 which could cause it to clobber git-annex

doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment

@@ -13,5 +13,5 @@ progress. And all that nontrivial work has in fact been done in order to
 support -J. It's just not enabled by default or for -J1.
 
 The reason git-annex has not yet switched to the concurrent output by
-default is that it assumes a VT100 compatable terminal.
+default is that it assumes a VT100 compatible terminal.
 """]]

doc/devblog/day_24__nearly_done_with_gcrypt.mdwn

@@ -13,7 +13,7 @@ about the new remote yet, and crashed (and was restarted knowing about it,
 so successfully sent any other files). So got sidetracked on fixing that.
 
 Also did some work to make the gpg bundled with git-annex on OSX be
-compatable with the config files written by MacGPG. At first I was going to
+compatible with the config files written by MacGPG. At first I was going to
 hack it to not crash on the options it didn't support, but it turned out
 that upgrading to version 1.4.14 actually fixed the problem that was making
 it build without support for DNS.

doc/devblog/day_426__grab_bag.mdwn

@@ -40,7 +40,7 @@ complicate it, and the hidden service side would need to listen on a unix
 socket, instead of the regular http port. It might be worth it to use http
 for tor, if it could be reused for git-annex http servers not on the tor
 network. But, then I'd have to make the http server support git pull and
-push over http in a way that's compatable with how git uses http, including
+push over http in a way that's compatible with how git uses http, including
 authentication. Which is a whole nother ball of complexity. So, I'm leaning
 instead to using a simple custom protocol something like:
 

doc/encryption.mdwn

@@ -79,7 +79,7 @@ repository with access to the encrypted data stored in the special remote.
 By default `gpg` is used for shared encryption, but it is also possible to
 use other programs that implement the Stateless OpenPGP command line
 interface. For example, to use Sequoia PGP's `sqop` command, configured to
-be backwards compatable with `gpg`:
+be backwards compatible with `gpg`:
 
     git config annex.shared-sop-command sqop
     git config annex.shared-sop-profile rfc4880

doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment

@@ -6,7 +6,7 @@
  content="""
 Sorry it took so long to get back to you.
 
-You do not necessarily have to have git-annex installed on your web server. But it will open up one of the nicest ways to use git-annex with a server, which is to put a bare git repository on the server, and let git-annex send the contents of large files to that repository. It's fine to install any old version of git-annex on the server, they're all forwards and backwards compatable.
+You do not necessarily have to have git-annex installed on your web server. But it will open up one of the nicest ways to use git-annex with a server, which is to put a bare git repository on the server, and let git-annex send the contents of large files to that repository. It's fine to install any old version of git-annex on the server, they're all forwards and backwards compatible.
 
 In any case, you need git-annex installed on any computers where you want to access the repository, certainly.
 

doc/projects/datalad/bugs-done/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs/comment_4_5c2c6003b45d78b9e0bee95f5a12c48c._comment

@@ -18,7 +18,7 @@ looks like a cache directory with a missing or empty base file, so it
 decides to clean it up. In the meantime the first process has written
 base and other files and so the rm fails. Also, the first process may
 succeed and end up running git-annex with some locale files missing
-(if the rm happened to delete those), resulting in incompatable
+(if the rm happened to delete those), resulting in incompatible
 system locales being used.
 
 So, it ought to defer cleaning up old caches until after it's made sure its

doc/special_remotes/S3.mdwn

@@ -63,7 +63,7 @@ the S3 remote.
   affect new objects sent to the remote, but not objects already
   stored there.
 
-* `host` - Specify in order to use a different, S3 compatable
+* `host` - Specify in order to use a different, S3 compatible
   service.
 
 * `region` - Specify the region to use. Only makes sense to use when

doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn

@@ -40,7 +40,7 @@ everyday problem for an average user.
 > 
 > Also, the assistant sets up it *own* .ssh/config hostname alias,
 > in order to make it use the special ssh key that it generates for the host.
-> So that is not compatable with using a ssh host alias you've set up.
+> So that is not compatible with using a ssh host alias you've set up.
 > Even if it knew about your alias, it would set up a new hostname alias, and
 > whatever machinery you have to update the alias would not work.
 >  

doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment

@@ -17,7 +17,7 @@ that almost everything uses. But in its favor:
 
 * --sameas already relies on special remotes using the same path form, and so
   it seems we're going to end up documenting which special remotes are
-  compatable. That information could even be encoded in the remotes and
+  compatible. That information could even be encoded in the remotes and
   git-annex sanity check uses of --sameas. 
 
   Perhaps --sameas is a slippery slope and this should not continue down it,

doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn

@@ -21,7 +21,7 @@ same encrypted special remote.
 
 Update: That's implemented now, when annex.shared-sop-command is configured
 it will be used for encryption=shared special remotes. It interoperates
-fine with using gpg, as long as the sop command uses a compatable profile
+fine with using gpg, as long as the sop command uses a compatible profile
 (setting annex.shared-sop-profile = rfc4880 is probably a good idea).
 
 Leaving this todo open because there are other encryption schemes than 

doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment

@@ -11,7 +11,7 @@ Eg, to use Sequoia's sqpop:
 	git config annex.shared-sop-command sqop
 
 That fully interoperates with gpg, though it's probably a good idea
-to specify an enryption profile that is backwards compatable if interop
+to specify an enryption profile that is backwards compatible if interop
 is a concern. Eg:
 
 	git config annex.shared-sop-profile rfc4880