Merge pull request #2129 from iterative/v1-tmp

Misc. (older) updates (from v1)

content/docs/command-reference/checkout.md

@@ -32,8 +32,8 @@ The execution of `dvc checkout` does the following:
   <abbr>outputs</abbr> against the actual files or directories in the
   <abbr>workspace</abbr> (similar to `dvc status`).
 
-  > Stage outputs must be defined in `dvc.yaml`. If found there but not in
-  > `dvc.lock`, they'll be skipped with a warning.
+  > Stage outputs must be defined in `dvc.yaml` (and `dvc.lock` contain their
+  > hash values), or they'll be skipped with a warning.
 
 - Missing data files or directories are restored from the cache. Those that
   don't match with `dvc.lock` or `.dvc` files are removed. See options `--force`
@@ -67,7 +67,8 @@ progress made by the checkout.
 There are two methods to restore a file missing from the cache, depending on the
 situation. In some cases the cache can be pulled from
 [remote storage](/doc/command-reference/remote) using `dvc pull`. In other cases
-the pipeline must be reproduced (using `dvc repro`) to regenerate its outputs.
+the [pipeline](/doc/command-reference/dag) must be reproduced (using
+`dvc repro`) to regenerate its outputs.
 
 ## Options
 

content/docs/command-reference/diff.md

@@ -62,7 +62,7 @@ for example when `dvc init` was used with the `--no-scm` option.
   Useful for debug purposes.
 
 - `--hide-missing` - do not list data missing from both workspace and cache
-  (`not in cache`). Only list files and directories which have been expliclity
+  (`not in cache`). Only list files and directories which have been explicitly
   added, modified, or deleted. This option does nothing when comparing two Git
   commits.
 

content/docs/command-reference/init.md

@@ -50,7 +50,7 @@ initializing DVC in the Git repo root:
 
 - DVC [internals](/doc/user-guide/project-structure/internal-files) (config
   file, cache directory, etc.) would be shared across different subdirectories.
-  This forces all of them to use the same DVC settings and
+  This forces all of them to use the same DVC configuration and
   [remote storage](/doc/command-reference/remote).
 
 - By default, DVC commands like `dvc pull` and `dvc repro` explore the whole
@@ -118,8 +118,9 @@ include:
 - SCM other than Git is being used. Even though there are DVC features that
   require DVC to be run in the Git repo, DVC can work well with other version
   control systems. Since DVC relies on simple `dvc.yaml` files to manage
-  <abbr>pipelines</abbr>, data, etc, they can be added into any version control
-  system, thus providing large data files and directories versioning.
+  [pipelines](/doc/command-reference/dag), data, etc, they can be added into any
+  version control system, thus providing large data files and directories
+  versioning.
 
 - There is no need to keep the history at all, e.g. having a deployment
   automation like running a data pipeline using `cron`.

content/docs/command-reference/install.md

@@ -107,20 +107,17 @@ repos:
 ```
 
 Note that by default, the pre-commit tool only installs `pre-commit` hooks. To
-enable the DVC `pre-push` and `post-checkout` hooks with pre-commit, you must
-explicitly configure pre-commit to install all the appropriate hook types:
+enable the `pre-push` and `post-checkout` hooks, you must explicitly configure
+the tool this way:
 
 ```dvc
 $ pre-commit install --hook-type pre-push --hook-type post-checkout --hook-type pre-commit
 ```
 
-This command can be run at any time before or after configuring the DVC hooks in
-`.pre-commit-config.yaml`.
-
 ## Options
 
 - `--use-pre-commit-tool` - configures DVC pre-commit, pre-push, post-checkout
-  Git hooks in the [pre-commit](https://pre-commit.com/) config file
+  Git hooks in the [pre-commit](#using-the-pre-commit-tool) config file
   (`.pre-commit-config.yaml`).
 
 - `-h`, `--help` - prints the usage/help message, and exit.

content/docs/command-reference/metrics/diff.md

@@ -21,19 +21,22 @@ positional arguments:
 ## Description
 
 This command provides a quick way to compare metrics among experiments in the
-repository history. All metrics defined in `dvc.yaml` are used by default. The
-differences shown by this command include the new value, and numeric difference
-(delta) from the previous value of metrics (rounded to 5 digits precision).
+repository history. The differences shown by this command include the new value,
+and numeric difference (delta) from the previous value of metrics (rounded to 5
+digits precision).
 
 `a_rev` and `b_rev` are Git commit hashes, tag, or branch names. If none are
 specified, `dvc metrics diff` compares metrics currently present in the
 <abbr>workspace</abbr> (uncommitted changes) with the latest committed versions
 (required). A single specified revision results in comparing the workspace and
 that version.
 
-> Note that unlike `dvc diff`, this command doesn't always need `dvc.yaml` files
-> to find metrics files (see `--targets` option). For that reason, it doesn't
-> require an existing DVC project to run in. It can work in any Git repo.
+All metrics defined in `dvc.yaml` are used by default, but specific metrics
+files can be specified with the `--targets` option
+
+> Note that targets don't necessarily have to be defined in `dvc.yaml`. For that
+> reason, this command doesn't require an existing DVC project to run in; It
+> works in any Git repo.
 
 Another way to display metrics is the `dvc metrics show` command, which just
 lists all the current metrics, without comparisons.

content/docs/command-reference/repro.md

@@ -1,9 +1,8 @@
 # repro
 
-Reproduce complete or partial <abbr>pipelines</abbr> by executing commands
-defined in their [stages](/doc/command-reference/run) in the correct order. The
-commands to be executed are determined by recursively analyzing dependencies and
-<abbr>outputs</abbr> of the target stages.
+Reproduce complete or partial [pipelines](/doc/command-reference/dag) by
+executing commands defined in their [stages](/doc/command-reference/run) in the
+correct order.
 
 ## Synopsis
 
@@ -14,8 +13,7 @@ usage: dvc repro [-h] [-q | -v] [-f] [-s] [-m] [--dry] [-i]
                  [targets [<target> ...]]
 
 positional arguments:
-  targets       Limit command scope to these .dvc or dvc.yaml files,
-                or stage names.
+  targets       Stages to reproduce. 'dvc.yaml' by default.
 ```
 
 > See [`targets`](#options) for more details.
@@ -24,19 +22,18 @@ positional arguments:
 
 Provides a way to regenerate data pipeline results, by restoring the dependency
 graph (a [DAG](https://en.wikipedia.org/wiki/Directed_acyclic_graph)) implicitly
-defined by the stages listed in `dvc.yaml` files. The commands defined in these
-stages are then be executed in the correct order.
+defined by the stages listed in `dvc.yaml`. The commands defined in these stages
+are then executed in the correct order.
 
-For stages with multiple commands (having a list or a multiline string in the
-`cmd` field), commands are run one after the other in the order they are
-defined. The failure of any command will halt the remaining stage execution, and
-raises an error.
+For stages with multiple commands (having a list in the `cmd` field), commands
+are run one after the other in the order they are defined. The failure of any
+command will halt the remaining stage execution, and raises an error.
 
 > Pipeline stages are defined in `dvc.yaml` (either manually or by using
 > `dvc run`) while initial data dependencies can be registered with `dvc add`.
 
-This command is similar to [Make](https://www.gnu.org/software/make/) in
-software build automation, but DVC captures build requirements
+`dvc repro` is similar to [Make](https://www.gnu.org/software/make/) in software
+build automation, but DVC captures build requirements
 ([dependencies and outputs](/doc/command-reference/run#dependencies-and-outputs))
 and <abbr>caches</abbr> the pipeline's <abbr>outputs</abbr> along the way.
 
@@ -72,7 +69,8 @@ files.
 
 Currently, `dvc repro` is not able to parallelize stage execution automatically.
 If you need to do this, you can launch `dvc repro` multiple times manually. For
-example, let's say a <abbr>pipeline</abbr> graph looks something like this:
+example, let's say a [pipelines](/doc/command-reference/dag) graph looks
+something like this:
 
 ```dvc
 $ dvc dag
@@ -139,8 +137,8 @@ up-to-date and only execute the final stage.
   `dvc commit` to finish the operation.
 
 - `-m`, `--metrics` - show metrics after reproduction. The target pipelines must
-  have at least one metrics file defined either with the `dvc metrics` command,
-  or by the `-M` or `-m` options of the `dvc run` command.
+  have at least one metrics file defined either with `dvc metrics` or by the
+  `-M` or `-m` options of `dvc run`
 
 - `--dry` - only print the commands that would be executed without actually
   executing the commands.

content/docs/command-reference/status.md

@@ -158,6 +158,9 @@ that.
 
 ```dvc
 $ dvc status
+baz.dvc:
+	changed outs:
+		modified:           baz
 dofoo:
 	changed deps:
 		modified:           baz
@@ -168,9 +171,6 @@ dobar:
 		modified:           foo
 	changed outs:
 		deleted:            bar
-baz.dvc:
-	changed outs:
-		modified:           baz
 ```
 
 This shows that for stage `dofoo`, the dependency `baz` and the output `foo`