docs: reflow some really long lines

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.

docs/faq.rst

@@ -167,9 +167,10 @@ really desperate (e.g. if you have no completed backup of that file and you'ld
 rather get a partial file extracted than nothing). You do **not** want to give
 that option under any normal circumstances.
 
-Note that checkpoints inside files are created only since version 1.1,
-make sure you have an up-to-date version of borgbackup if you want to continue instead of retransferring a huge file.
-In some cases, there is only an outdated version shipped with your distribution (e.g. Debian). See :ref:`installation`.
+Note that checkpoints inside files are created only since version 1.1, make
+sure you have an up-to-date version of borgbackup if you want to continue
+instead of retransferring a huge file. In some cases, there is only an outdated
+version shipped with your distribution (e.g. Debian). See :ref:`installation`.
 
 How can I backup huge file(s) over a unstable connection?
 ---------------------------------------------------------
@@ -240,8 +241,8 @@ Apart from these very rare errors there are two main causes of errors:
 (i) Defective hardware: described below.
 (ii) Bugs in software (Borg, operating system, libraries):
      Ensure software is up to date.
-     Check whether the issue is caused by any fixed bugs described in :ref:`important_notes`.
-
+     Check whether the issue is caused by any fixed bugs described in
+     :ref:`important_notes`.
 
 .. rubric:: Finding defective hardware
 
@@ -703,9 +704,14 @@ already used.
 By default, ctime (change time) is used for the timestamps to have a rather
 safe change detection (see also the --files-cache option).
 
-Furthermore, pathnames recorded in files cache are always absolute, even if you specify
-source directories with relative pathname. If relative pathnames are stable, but absolute are
-not (for example if you mount a filesystem without stable mount points for each backup or if you are running the backup from a filesystem snapshot whose name is not stable), borg will assume that files are different and will report them as 'added', even though no new chunks will be actually recorded for them. To avoid this, you could bind mount your source directory in a directory with the stable path.
+Furthermore, pathnames recorded in files cache are always absolute, even if you
+specify source directories with relative pathname. If relative pathnames are
+stable, but absolute are not (for example if you mount a filesystem without
+stable mount points for each backup or if you are running the backup from a
+filesystem snapshot whose name is not stable), borg will assume that files are
+different and will report them as 'added', even though no new chunks will be
+actually recorded for them. To avoid this, you could bind mount your source
+directory in a directory with the stable path.
 
 .. _always_chunking:
 
@@ -733,10 +739,11 @@ BORG_FILES_CACHE_TTL to at least 26 (or maybe even a small multiple of that),
 it would be much faster.
 
 Another possible reason is that files don't always have the same path, for
-example if you mount a filesystem without stable mount points for each backup or if you are running the backup from a filesystem snapshot whose name is not stable.
-If the directory where you mount a filesystem is different every time,
-Borg assumes they are different files. This is true even if you backup these files with relative pathnames - borg uses full
-pathnames in files cache regardless.
+example if you mount a filesystem without stable mount points for each backup
+or if you are running the backup from a filesystem snapshot whose name is not
+stable. If the directory where you mount a filesystem is different every time,
+Borg assumes they are different files. This is true even if you backup these
+files with relative pathnames - borg uses full pathnames in files cache regardless.
 
 
 Is there a way to limit bandwidth with Borg?
@@ -765,7 +772,8 @@ Add BORG_RSH environment variable to use pipeviewer wrapper script with ssh.
 
     export BORG_RSH='/usr/local/bin/pv-wrapper ssh'
 
-Now Borg will be bandwidth limited. Nice thing about pv is that you can change rate-limit on the fly:
+Now Borg will be bandwidth limited. The nice thing about ``pv`` is that you can
+change rate-limit on the fly:
 
 ::
 
@@ -944,13 +952,16 @@ Borg is a fork of `Attic`_ and maintained by "`The Borg collective`_".
 
 Here's a (incomplete) list of some major changes:
 
-* lots of attic issues fixed (see `issue #5 <https://github.com/borgbackup/borg/issues/5>`_),
+* lots of attic issues fixed
+  (see `issue #5 <https://github.com/borgbackup/borg/issues/5>`_),
   including critical data corruption bugs and security issues.
-* more open, faster paced development (see `issue #1 <https://github.com/borgbackup/borg/issues/1>`_)
+* more open, faster paced development
+  (see `issue #1 <https://github.com/borgbackup/borg/issues/1>`_)
 * less chunk management overhead (less memory and disk usage for chunks index)
 * faster remote cache resync (useful when backing up multiple machines into same repo)
 * compression: no, lz4, zstd, zlib or lzma compression, adjustable compression levels
-* repokey replaces problematic passphrase mode (you can't change the passphrase nor the pbkdf2 iteration count in "passphrase" mode)
+* repokey replaces problematic passphrase mode (you can't change the passphrase
+  nor the pbkdf2 iteration count in "passphrase" mode)
 * simple sparse file support, great for virtual machine disk files
 * can read special files (e.g. block devices) or from stdin, write to stdout
 * mkdir-based locking is more compatible than attic's posix locking

docs/installation.rst

@@ -111,9 +111,10 @@ alias for ``borg mount``::
 
     ln -s /usr/local/bin/borg /usr/local/bin/borgfs
 
-Note that the binary uses /tmp to unpack Borg with all dependencies.
-It will fail if /tmp has not enough free space or is mounted with the ``noexec`` option.
-You can change the temporary directory by setting the ``TEMP`` environment variable before running Borg.
+Note that the binary uses /tmp to unpack Borg with all dependencies. It will
+fail if /tmp has not enough free space or is mounted with the ``noexec``
+option. You can change the temporary directory by setting the ``TEMP``
+environment variable before running Borg.
 
 If a new version is released, you will have to manually download it and replace
 the old version using the same steps as shown above.
@@ -230,8 +231,8 @@ dependencies::
     pip3 install virtualenv
 
 For FUSE support to mount the backup archives, you need at least version 3.0 of
-FUSE for OS X, which is available via `github <https://github.com/osxfuse/osxfuse/releases/latest>`__,
-or via homebrew::
+FUSE for OS X, which is available via `github
+<https://github.com/osxfuse/osxfuse/releases/latest>`__, or via homebrew::
 
     brew cask install osxfuse
 

docs/quickstart.rst

@@ -113,7 +113,8 @@ common techniques to achieve this.
 
 - Avoid running any programs that might change the files.
 
-- Snapshot files, filesystems, container storage volumes, or logical volumes.  LVM or ZFS might be useful here.
+- Snapshot files, filesystems, container storage volumes, or logical volumes.
+  LVM or ZFS might be useful here.
 
 - Dump databases or stop the database servers.
 

docs/resources.rst

@@ -13,26 +13,38 @@ Videos, Talks, Presentations
 
 Some of them refer to attic, but you can do the same stuff (and more) with borgbackup.
 
-- `BorgBackup Installation and Basic Usage <https://asciinema.org/a/28691?autoplay=1&speed=2>`_  (english screencast)
+- `BorgBackup Installation and Basic Usage
+  <https://asciinema.org/a/28691?autoplay=1&speed=2>`_  (english screencast)
 
-- `TW's slides for borgbackup talks / lightning talks <https://slides.com/thomaswaldmann>`_ (just grab the latest ones)
+- `TW's slides for borgbackup talks / lightning talks
+  <https://slides.com/thomaswaldmann>`_ (just grab the latest ones)
 
-- `Attic / Borg Backup talk from GPN 2015 (media.ccc.de) <https://media.ccc.de/browse/conferences/gpn/gpn15/gpn15-6942-attic_borg_backup.html#video>`_
-- `Attic / Borg Backup talk from GPN 2015 (youtube) <https://www.youtube.com/watch?v=Nb5nXEKSN-k>`_
+- `Attic / Borg Backup talk from GPN 2015 (media.ccc.de)
+  <https://media.ccc.de/browse/conferences/gpn/gpn15/gpn15-6942-attic_borg_backup.html#video>`_
+- `Attic / Borg Backup talk from GPN 2015 (youtube)
+  <https://www.youtube.com/watch?v=Nb5nXEKSN-k>`_
 
-- `Attic talk from Easterhegg 2015 (media.ccc.de) <https://media.ccc.de/v/eh15_-_49_-__-_saal_-_201504042130_-_attic_-_the_holy_grail_of_backups_-_thomas#video>`_
-- `Attic talk from Easterhegg 2015 (youtube) <https://www.youtube.com/watch?v=96VEAAFDtJw>`_
+- `Attic talk from Easterhegg 2015 (media.ccc.de)
+  <https://media.ccc.de/v/eh15_-_49_-__-_saal_-_201504042130_-_attic_-_the_holy_grail_of_backups_-_thomas#video>`_
+- `Attic talk from Easterhegg 2015 (youtube)
+  <https://www.youtube.com/watch?v=96VEAAFDtJw>`_
 
-- `Attic Backup: Mount your encrypted backups over ssh (youtube) <https://www.youtube.com/watch?v=BVXDFv9YMp8>`_
+- `Attic Backup: Mount your encrypted backups over ssh (youtube)
+  <https://www.youtube.com/watch?v=BVXDFv9YMp8>`_
 
-- `Evolution of Borg (youtube) <https://www.youtube.com/watch?v=K4k_4wDkG6Q>`_
+- `Evolution of Borg (youtube)
+  <https://www.youtube.com/watch?v=K4k_4wDkG6Q>`_
 
 .. _software:
 
 Software
 --------
 
-- `BorgWeb - a very simple web UI for BorgBackup <https://borgweb.readthedocs.io/>`_
-- some other stuff found at the `BorgBackup Github organisation <https://github.com/borgbackup/>`_
-- `borgmatic <https://torsion.org/borgmatic/>`_ - simple wrapper script for BorgBackup that creates and prunes backups
-- `vorta <https://github.com/borgbase/vorta>` - A gui for borg backup, based on python and qt.
+- `BorgWeb - a very simple web UI for BorgBackup
+  <https://borgweb.readthedocs.io/>`_
+- some other stuff found at the `BorgBackup Github organisation
+  <https://github.com/borgbackup/>`_
+- `borgmatic <https://torsion.org/borgmatic/>`_ - simple wrapper script for
+  BorgBackup that creates and prunes backups
+- `vorta <https://github.com/borgbase/vorta>` - A gui for borg backup, based
+  on python and qt.

docs/support.rst

@@ -14,8 +14,8 @@ Please see https://www.borgbackup.org/ for free and paid support and service opt
 Security
 --------
 
-In case you discover a security issue, please use this contact for reporting it privately
-and please, if possible, use encrypted E-Mail:
+In case you discover a security issue, please use this contact for reporting it
+privately and please, if possible, use encrypted E-Mail:
 
 Thomas Waldmann <tw@waldmann-edv.de>
 
@@ -27,13 +27,19 @@ use the **full fingerprint** to check that you got the correct key.
 Verifying signed releases
 -------------------------
 
-`Releases <https://github.com/borgbackup/borg/releases>`_ are signed with the same GPG key and a .asc file is provided for each binary.
+`Releases <https://github.com/borgbackup/borg/releases>`_ are signed with the
+same GPG key and a .asc file is provided for each binary.
 
-To verify a signature, the public key needs to be known to GPG. It can be imported into the local keystore from a keyserver with the fingerprint::
+To verify a signature, the public key needs to be known to GPG. It can be
+imported into the local keystore from a keyserver with the fingerprint::
 
       gpg --recv-keys "6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393"
 
-If GPG successfully imported the key, the output should be (among other things): 'Total number processed: 1'.
+If GPG successfully imported the key, the output should include (among other things)::
+
+      ...
+      gpg: Total number processed: 1
+      ...
 
 To verify for example the signature of the borg-linux64 binary::
 
@@ -51,4 +57,5 @@ GPG outputs if it finds a good signature. The output should look similar to this
       Primary key fingerprint: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393
       Subkey fingerprint: 2F81 AFFB AB04 E11F E8EE 65D4 243A CFA9 51F7 8E01
 
-If you want to make absolutely sure that you have the right key, you need to verify it via another channel and assign a trust-level to it.
+If you want to make absolutely sure that you have the right key, you need to
+verify it via another channel and assign a trust-level to it.