Backport from master: Make clear that absolute paths always go into the matcher as if they are relative (without leading slash). Adapt all examples accordingly.
docs: permissions note rewritten to make it less confusing
Original wording was confusing "Avoid to create a mixup of users and permissions in your repository (or cache)." is not clear, what should be avoided?
Also implement some feedback of @jdchristensen.
Co-authored-by: Thomas Waldmann <tw@waldmann-edv.de>
I used `grep -Pnr '.{100}' *.rst` to find lines >100 characters long and
reflowed them where reasonable. Line length in the docs isn't too important (it
doesn't matter once they're compiled), but it's nice not to have super-long
lines in one's editor.
Fix various code blocks in the docs
- rst markup: put codeblock markup on separate line to make it better visible / separate it from normal text colons.
- borg help texts in archiver.py: put codeblock markup instead of colon - that way it looks like a single colon when using the cli help and also works as code block markup.
docs: fix and deduplicate encryption quickstart docs
just refer to "borg init" docs rather than duplicating it in quickstart.
also: s/archive/repository/
This command works similarly to "git config" - it parses repo and
cache configs to get, set, and delete values. It only works on local
repos so a malicious client can't e.g. override their storage quota
or reset the append_only flag.
Add tests for borg config
Add documentation for borg config
Change manual config edits -> borg config
There were a couple places in the documentation where it was advised
to edit the repository or cache config file, a process that is stream-
lined by borg config.
I'm still hoping that a destination switch can be added (requested long ago in https://github.com/jborg/attic/issues/195), but in the meantime this may help. I'm guessing this clobbers any existing files.
move the note about free space after the step by step example. it is
unlikely that users will hit out of space conditions on their first
run, and at the end of the example, they will see the not anyways.
this is to make the documentation less scary for new users and easier
to use.
