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 ^^^
This commit is contained in:
parent
87e2ae2014
commit
9c2ab31549
12 changed files with 12 additions and 12 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
>
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue