run fix

Author: yathomasi

packages/example/content/docs/command-reference/add.md

@@ -350,11 +350,10 @@ When you want to add a large dataset that is outside of your
 it into the <abbr>workspace</abbr> first. But you may not have enough local
 storage space.
 
-You can however set up an [external cache] that can handle the data. To avoid
-ever making a local copy, target the outside data with `dvc add` while
-specifying an `--out` (`-o`) path inside of your project. This way the data will
-be transferred to the <abbr>cache</abbr> directly, and then [linked] into your
-workspace.
+You can however set up an [external cache] that can handle the data. To avoid ever
+making a local copy, target the outside data with `dvc add` while specifying an `--out`
+(`-o`) path inside of your project. This way the data will be transferred to the
+<abbr>cache</abbr> directly, and then [linked] into your workspace.
 
 Let's add a `data.xml` file via HTTP, putting it in `./data.xml`:
 
@@ -389,8 +388,8 @@ dataset, but you still want to track it in the <abbr>project</abbr> so it can be
 [pulled](/doc/command-reference/plots) later.
 
 As long as you have setup [remote storage] that can handle the data, this can be
-achieved with the `--to-remote` flag. It creates a `.dvc` file without
-downloading anything, transferring a target directly to a DVC remote instead:
+achieved with the `--to-remote` flag. It creates a `.dvc` file without downloading
+anything, transferring a target directly to a DVC remote instead:
 
 Let's add a `data.xml` file via HTTP straight to remote:
 

packages/example/content/docs/command-reference/commit.md

@@ -50,8 +50,8 @@ Some scenarios for `dvc commit` include:
   versions without having to execute stage commands.
 
 - Sometimes after executing a <abbr>stage</abbr>, we realize that not all of its
-  dependencies or outputs are defined in `dvc.yaml`. It is possible to [add the
-  missing deps/outs] without having to re-execute stages, and `dvc commit` is
+  dependencies or outputs are defined in `dvc.yaml`. It is possible to [add
+  the missing deps/outs] without having to re-execute stages, and `dvc commit` is
   needed to finalize the operation (see link).
 
 - It's also possible to execute stage commands by hand (without `dvc repro`), or

packages/example/content/docs/command-reference/exp/branch.md

@@ -17,7 +17,8 @@ positional arguments:
 
 Makes a given Git [`branch`] containing the target `experiment`. This makes the
 experiment into a [regular commit], or several in the case of [checkpoint
-experiments] (one per checkpoint).
+experiments]
+(one per checkpoint).
 
 The new `branch` will be based on the experiment's parent commit (`HEAD` at the
 time that the experiment was run). Note that DVC **does not** switch into the

packages/example/content/docs/command-reference/exp/init.md

@@ -37,8 +37,8 @@ Repository structure assumed by default:
 ```
 
 > Note that `dvc exp init` expects at least a `params.yaml` file present. DVC
-> reads it to find parameters to include in the [stage definition]. It can
-> however be omitted when using the `--explicit` and/or `-i` flags.
+> reads it to find parameters to include in the [stage definition]. It can however
+> be omitted when using the `--explicit` and/or `-i` flags.
 
 You must always provide a command that runs your experiment(s). It can be given
 either directly [as an argument](#the-command-argument), or by using the
@@ -48,8 +48,8 @@ wrapped as a <abbr>stage</abbr> that `dvc exp run` can execute.
 Different types of stages are supported, such as `dl` (deep learning) which uses
 [DVCLive](/doc/dvclive) to monitor [checkpoints] during training of ML models.
 
-> `dvc exp init` is intended as a quick way to start running [DVC Experiments].
-> See the `dvc.yaml` specification for complex data pipelines.
+> `dvc exp init` is intended as a quick way to start running [DVC Experiments]. See
+> the `dvc.yaml` specification for complex data pipelines.
 
 [stage definition]:
   /doc/user-guide/project-structure/pipelines-files#stage-entries

packages/example/content/docs/command-reference/exp/run.md

@@ -33,25 +33,23 @@ directories, etc.
 Use the `--set-param` (`-S`) option as a shortcut to change
 <abbr>parameter</abbr> values [on-the-fly] before running the experiment.
 
-It's possible to [queue experiments] for later execution with the `--queue`
-flag. To actually run them, use `dvc exp run --run-all`. Queued experiments are
-run sequentially by default, but can be run in parallel using the `--jobs`
-option.
+It's possible to [queue experiments] for later execution with the `--queue` flag.
+To actually run them, use `dvc exp run --run-all`. Queued experiments are run sequentially
+by default, but can be run in parallel using the `--jobs` option.
 
 > ⚠️ Parallel runs are experimental and may be unstable. Make sure you're using
 > a number of jobs that your environment can handle (no more than the CPU
 > cores).
 
-It's also possible to run special [checkpoint experiments] that log the
-execution progress (useful for deep learning ML). The `--rev` and `--reset`
-options have special uses for these.
+It's also possible to run special [checkpoint experiments] that log the execution
+progress (useful for deep learning ML). The `--rev` and `--reset` options have special
+uses for these.
 
 > 📖 See the [Running Experiments] guide for more details on all these features.
 
 [Review] your experiments with `dvc exp show`. Successful ones can be [made
-persistent] by restoring them via `dvc exp branch` or `dvc exp apply` and
-committing them to the Git repo. Unnecessary ones can be [cleared] with
-`dvc exp gc`.
+persistent] by restoring them via `dvc exp branch` or `dvc exp apply` and committing
+them to the Git repo. Unnecessary ones can be [cleared] with `dvc exp gc`.
 
 [on-the-fly]: #example-modify-parameters-on-the-fly
 [queue experiments]:

packages/example/content/docs/command-reference/gc.md

@@ -25,10 +25,10 @@ details.
 The data kept is determined by reading the <abbr>DVC files</abbr> in the set of
 commits of the given scope.
 
-> Note that `dvc gc` tries to fetch missing [`.dir` files] from remote storage
-> to local cache in order to determine which files should exist inside cached
-> directories. These files may be missing if the cache was previously garbage
-> collected, in a newly cloned copy of the repo, etc.
+> Note that `dvc gc` tries to fetch missing [`.dir` files] from remote storage to
+> local cache in order to determine which files should exist inside cached directories.
+> These files may be missing if the cache was previously garbage collected, in a
+> newly cloned copy of the repo, etc.
 
 Unless the `--cloud` option is used, any files collected from the cache can be
 restored using `dvc fetch`, as long as they have been previously uploaded with
@@ -96,15 +96,14 @@ project we want to clear.
 
   > \* Not including [DVC experiments]
 
-- `--all-experiments` keep cached objects referenced in all [DVC experiments],
-  as well as in the workspace (implying `-w`). This preserves the project's
-  [experimental](/doc/user-guide/experiment-management) data (including
-  checkpoints). See also `dvc exp gc`.
+- `--all-experiments` keep cached objects referenced in all [DVC experiments], as
+  well as in the workspace (implying `-w`). This preserves the project's [experimental](/doc/user-guide/experiment-management)
+  data (including checkpoints). See also `dvc exp gc`.
 
-- `-p <paths>`, `--projects <paths>` - if a single remote or a single [cache is
-  shared] among different projects, this option can be used to specify a list of
-  them (each project is a path) to keep data that is currently referenced from
-  them.
+- `-p <paths>`, `--projects <paths>` - if a single remote or a single [cache
+  is shared] among different projects, this option can be used to specify a list
+  of them (each project is a path) to keep data that is currently referenced
+  from them.
 
 - `-c`, `--cloud` - remove files in remote storage in addition to local cache.
   **This option is dangerous.** The default remote is used unless a specific one

packages/example/content/docs/command-reference/import-url.md

@@ -368,8 +368,8 @@ dataset, but you still want to track it in the <abbr>project</abbr> so it can be
 [pulled](/doc/command-reference/plots) later.
 
 As long as you have setup [remote storage] that can handle the data, this can be
-achieved with the `--to-remote` flag. It creates an import `.dvc` file without
-downloading anything, transferring a target directly to a DVC remote instead.
+achieved with the `--to-remote` flag. It creates an import `.dvc` file without downloading
+anything, transferring a target directly to a DVC remote instead.
 
 Let's import a `data.xml` file via HTTP straight to remote:
 

packages/example/content/docs/command-reference/pull.md

@@ -20,10 +20,9 @@ positional arguments:
 
 The `dvc push` and `dvc pull` commands are the means for uploading and
 downloading data to and from remote storage (S3, SSH, GCS, etc.). These commands
-are similar to `git push` and `git pull`, respectively. [Data sharing] across
-environments and preserving data versions (input datasets, intermediate results,
-models, [metrics](/doc/command-reference/metrics), etc.) remotely are the most
-common use cases for these commands.
+are similar to `git push` and `git pull`, respectively. [Data sharing] across environments
+and preserving data versions (input datasets, intermediate results, models, [metrics](/doc/command-reference/metrics),
+etc.) remotely are the most common use cases for these commands.
 
 `dvc pull` downloads tracked data from
 [remote storage](/doc/command-reference/remote) to the <abbr>cache</abbr>, and

packages/example/content/docs/command-reference/push.md

@@ -20,10 +20,9 @@ positional arguments:
 
 The `dvc push` and `dvc pull` commands are the means for uploading and
 downloading data to and from remote storage (S3, SSH, GCS, etc.). These commands
-are similar to `git push` and `git pull`, respectively. [Data sharing] across
-environments, and preserving data versions (input datasets, intermediate
-results, models, [metrics](/doc/command-reference/metrics), etc.) remotely are
-the most common use cases for these commands.
+are similar to `git push` and `git pull`, respectively. [Data sharing] across environments,
+and preserving data versions (input datasets, intermediate results, models, [metrics](/doc/command-reference/metrics),
+etc.) remotely are the most common use cases for these commands.
 
 `dvc push` uploads data from the <abbr>cache</abbr> to
 [remote storage](/doc/command-reference/remote).

packages/example/content/docs/command-reference/remote/modify.md

@@ -890,8 +890,8 @@ by HDFS. Read more about by expanding the WebHDFS section in
   $ dvc remote modify myremote kerberos true
   ```
 
-- `kerberos_principal` - [Kerberos principal] to use, in case you have multiple
-  ones (for example service accounts). Only used if `kerberos` is `true`.
+- `kerberos_principal` - [Kerberos principal] to use, in case you have multiple ones
+  (for example service accounts). Only used if `kerberos` is `true`.
 
   ```dvc
   $ dvc remote modify myremote kerberos_principal myprincipal