Expand the first-run documentation

- Clarified that the Usage commands in the README apply to both new and
  existing projects
- Move information about the vendor directory backup into the README.
  This gives the user the necessary context as soon as they would need
  it, rather than needing to stumble upon it (somewhat buried) in the FAQ.

Author: afeld

README.md

@@ -36,13 +36,15 @@ Get the tool via
 $ go get -u github.com/golang/dep/cmd/dep
 ```
 
-Typical usage on a new repo might be
+Typical usage - either on a new project or converting an existing one - is
 
 ```sh
 $ dep init
 $ dep ensure -update
 ```
 
+If your project was already using a `vendor/` directory, it was backed up to `_vendor-TIMESTAMP/`.
+
 To update a dependency to a new version, you might run
 
 ```sh
@@ -51,6 +53,10 @@ $ dep ensure github.com/pkg/errors@^0.8.0
 
 See the help text for more detailed usage instructions.
 
+```sh
+$ dep help ensure
+```
+
 ## Feedback
 
 Feedback is greatly appreciated.

docs/FAQ.md

@@ -24,7 +24,6 @@ Summarize the question and quote the reply, linking back to the original comment
 * [Why did `dep` use a different revision for package X instead of the revision in the lock file?](#why-did-dep-use-a-different-revision-for-package-x-instead-of-the-revision-in-the-lock-file)
 * [Why is `dep` slow?](#why-is-dep-slow)
 * [How does `dep` handle symbolic links?](#how-does-dep-handle-symbolic-links)
-* [`dep` deleted my files in the vendor directory!](#dep-deleted-my-files-in-the-vendor-directory)
 
 ## Best Practices
 * [Should I commit my vendor directory?](#should-i-commit-my-vendor-directory)
@@ -249,13 +248,6 @@ When `dep` is invoked with a project root that is a symlink, it will be resolved
 
 This is the only symbolic link support that `dep` really intends to provide. In keeping with the general practices of the `go` tool, `dep` tends to either ignore symlinks (when walking) or copy the symlink itself, depending on the filesystem operation being performed.
 
-## `dep` deleted my files in the vendor directory!
-If you just ran `dep init`, there should be a copy of your original vendor directory named `_vendor-TIMESTAMP` in your project root. The other commands do not make a backup before modifying the vendor directory.
-
-> dep assumes complete control of vendor/, and may indeed blow things away if it feels like it.
--[@peterbourgon in #206](https://github.com/golang/dep/issues/206#issuecomment-277139419)
-
-
 ## Best Practices
 ### Should I commit my vendor directory?
 
@@ -276,7 +268,7 @@ It's up to you:
 >  I would recommend against ever working in your vendor directory since dep will overwrite any changes. It’s too easy to lose work that way.
 -[@carolynvs in #706](https://github.com/golang/dep/issues/706#issuecomment-305807261)
 
-If you have a fork, add a `[[constraint]]` entry for the project in `Gopkg.toml` and set `source` to the fork source. This will ensure that `dep` will fetch the project from the fork instead of the original source. 
+If you have a fork, add a `[[constraint]]` entry for the project in `Gopkg.toml` and set `source` to the fork source. This will ensure that `dep` will fetch the project from the fork instead of the original source.
 Otherwise, if you want to test changes locally, you can delete the package from `vendor/` and make changes directly in `GOPATH/src/*package*` so that your changes are picked up by the go tool chain.
 
 ## How do I roll releases that `dep` will be able to use?