Merge pull request #1054 from iterative/skshetry/checkout-pr

cmd-ref: document checkout displaying changes

content/docs/command-reference/checkout.md

@@ -37,9 +37,9 @@ The execution of `dvc checkout` does the following:
   DVC-files. Scanning is limited to the given `targets` (if any). See also
   options `--with-deps` and `--recursive` below.
 
-- Missing data files or directories, or those that don't match with any
-  DVC-file, are restored from the <abbr>cache</abbr>. See options `--force` and
-  `--relink`.
+- Missing data files or directories are restored from the <abbr>cache</abbr>.
+  Those that don't match with any DVC-file are removed. See options `--force`
+  and `--relink`. A list of the changes done is printed.
 
 By default, this command tries not make copies of cached files in the workspace,
 using reflinks instead when supported by the file system (refer to
@@ -58,18 +58,18 @@ restoring any file size will be almost instantaneous.
 > `cache.slow_link_warning` config option to `false` with `dvc config cache`.
 
 This command will fail to checkout files that are missing from the cache. In
-such a case, `dvc checkout` prints a warning message. It also lists removed
-files. Any files that can be checked out without error will be restored without
-being reported individually.
+such a case, `dvc checkout` prints a warning message. It also lists the partial
+progress made by the checkout.
 
 There are two methods to restore a file missing from the cache, depending on the
 situation. In some cases a pipeline must be reproduced (using `dvc repro`) to
-regenerate its outputs. (See also `dvc pipeline`.) In other cases the cache can
+regenerate its outputs (see also `dvc pipeline`). In other cases the cache can
 be pulled from remote storage using `dvc pull`.
 
 ## Options
 
-- `--summary` - show summary of the changes.
+- `--summary` - display a short summary of the changes done by this command in
+  the workspace, instead of a full list of changes.
 
 - `-R`, `--recursive` - determines the files to checkout by searching each
   target directory and its subdirectories for DVC-files to inspect. If there are
@@ -149,7 +149,7 @@ This project comes with a predefined HTTP
 [remote storage](/doc/command-reference/remote). We can now just run `dvc pull`
 that will fetch and checkout the most recent `model.pkl`, `data.xml`, and other
 files that are tracked by DVC. The model file hash
-`3863d0e317dee0a55c4e59d2ec0eef33` will be used in the `train.dvc`
+`662eb7f64216d9c2c1088d0a5e2c6951` will be used in the `train.dvc`
 [stage file](/doc/command-reference/run):
 
 ```dvc
@@ -190,6 +190,8 @@ doesn't track those files; DVC does, so we must do this:
 ```dvc
 $ dvc fetch
 $ dvc checkout
+M       model.pkl
+M       data\features\
 
 $ md5 model.pkl
 MD5 (model.pkl) = 43630cce66a2432dcecddc9dd006d0a7

content/docs/use-cases/shared-development-server.md

@@ -96,7 +96,7 @@ manually. After this, they could decide to continue building this
 ```dvc
 $ git pull
 $ dvc checkout
-  # Data is linked from cache to workspace.
+A       raw  # Data is linked from cache to workspace.
 $ dvc run -d clean -o processed ./process.py clean process
 $ git add processed.dvc
 $ git commit -m "process clean data"
@@ -108,4 +108,5 @@ And now you can just as easily make their work appear in your workspace with:
 ```dvc
 $ git pull
 $ dvc checkout
+A       processed
 ```

content/docs/use-cases/versioning-data-and-model-files.md

@@ -92,6 +92,8 @@ file. Let's consider the full checkout first. It's quite straightforward:
 ```dvc
 $ git checkout v1.0
 $ dvc checkout
+M       images
+M       model.pkl
 ```
 
 These commands will restore the workspace to the first snapshot we made - code,
@@ -105,8 +107,9 @@ the previous dataset only, we can do something like this (make sure that you
 don't have uncommitted changes in the `data.dvc`):
 
 ```dvc
-$ git checkout v1.0 data.dvc
-$ dvc checkout data.dvc
+$ git checkout v1.0 images.dvc
+$ dvc checkout images.dvc
+M       images
 ```
 
 If you run `git status` you will see that `data.dvc` is modified and currently