mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Fix compatable typo (yet to add to codespell)

Browse source 
=== Do not change lines below ===
{
 "chain": [],
 "cmd": "git-sedi compatable compatible",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^
This commit is contained in:
Yaroslav Halchenko 2024-04-06 15:52:01 +02:00 • committed by Joey Hess
parent 87e2ae2014
commit 9c2ab31549
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
12 changed files with 12 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

2
CHANGELOG
View file

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

2
doc/bugs/git_annex_should_check_that_stdout_isatty_when_reporting_progress/comment_2_e2139a3d1d06772d06992a38140e51d3._comment
View file

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

2
doc/devblog/day_24__nearly_done_with_gcrypt.mdwn
View file

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

2
doc/devblog/day_426__grab_bag.mdwn
View file

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

2
doc/encryption.mdwn
View file

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

2
doc/forum/first-time_setup_git-annex/comment_1_a58d83ee3a7c2251d9a775847223f8ca._comment
View file

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

2
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
View file

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

2
doc/special_remotes/S3.mdwn
View file

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

2
doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
View file

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

2
doc/todo/generic_readonly_http_remote/comment_2_c81b458a8ee0f15950adbd32dd168972._comment
View file

@ -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,

2
doc/todo/support_using_Stateless_OpenPGP_instead_of_gpg.mdwn
View file

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

2
doc/todo/whishlist__58___GPG_alternatives_like_AGE/comment_9_18861f94b677a40c2d1c0014338231c6._comment
View file

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