point users to --new-from-rev=HEAD~ for CI setups in --help

Although the FAQ does eventually mention that
--new-from-rev=origin/master is the right way, --help does not and
using --new in CI is a terrible pitfall.

Make --help point users to -new-from-rev=HEAD~ for CI setups.

Also use HEAD~ instead of origin/master, since HEAD~ is more
universally applicable, e.g. if golangci-lint is ran against a release
branch.

Author: rski

README.md

@@ -387,7 +387,8 @@ Flags:
       --max-same-issues int         Maximum count of issues with the same text. Set to 0 to disable (default 3)
   -n, --new                         Show only new issues: if there are unstaged changes or untracked files, only those changes are analyzed, else only changes in HEAD~ are analyzed.
                                     It's a super-useful option for integration of golangci-lint into existing large codebase.
-                                    It's not practical to fix all existing issues at the moment of integration: much better don't allow issues in new code
+                                    It's not practical to fix all existing issues at the moment of integration: much better to not allow issues in new code.
+                                    For CI setups, prefer --new-from-rev=HEAD~, as --new can skip linting the current patch if any scripts generate unstaged files before golangci-lint runs.
       --new-from-rev REV            Show only new issues created after git revision REV
       --new-from-patch PATH         Show only new issues created in git patch with file path PATH
   -h, --help                        help for run
@@ -671,7 +672,7 @@ You can integrate it yourself, see this [wiki page](https://github.com/golangci/
 
 **It's cool to use `golangci-lint` when starting a project, but what about existing projects with large codebase? It will take days to fix all found issues**
 
-We are sure that every project can easily integrate `golangci-lint`, even the large one. The idea is to not fix all existing issues. Fix only newly added issue: issues in new code. To do this setup CI (or better use [GolangCI](https://golangci.com) to run `golangci-lint` with option `--new-from-rev=origin/master`. Also, take a look at option `-n`.
+We are sure that every project can easily integrate `golangci-lint`, even the large one. The idea is to not fix all existing issues. Fix only newly added issue: issues in new code. To do this setup CI (or better use [GolangCI](https://golangci.com)) to run `golangci-lint` with option `--new-from-rev=HEAD~1`. Also, take a look at option `--new`, but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit. In that regard `--new-from-rev=HEAD~1` is safer.
 By doing this you won't create new issues in your code and can choose fix existing issues (or not).
 
 **How to use `golangci-lint` in CI (Continuous Integration)?**

README.tmpl.md

@@ -327,7 +327,7 @@ You can integrate it yourself, see this [wiki page](https://github.com/golangci/
 
 **It's cool to use `golangci-lint` when starting a project, but what about existing projects with large codebase? It will take days to fix all found issues**
 
-We are sure that every project can easily integrate `golangci-lint`, even the large one. The idea is to not fix all existing issues. Fix only newly added issue: issues in new code. To do this setup CI (or better use [GolangCI](https://golangci.com) to run `golangci-lint` with option `--new-from-rev=origin/master`. Also, take a look at option `-n`.
+We are sure that every project can easily integrate `golangci-lint`, even the large one. The idea is to not fix all existing issues. Fix only newly added issue: issues in new code. To do this setup CI (or better use [GolangCI](https://golangci.com)) to run `golangci-lint` with option `--new-from-rev=HEAD~1`. Also, take a look at option `--new`, but consider that CI scripts that generate unstaged files will make `--new` only point out issues in those files and not in the last commit. In that regard `--new-from-rev=HEAD~1` is safer.
 By doing this you won't create new issues in your code and can choose fix existing issues (or not).
 
 **How to use `golangci-lint` in CI (Continuous Integration)?**

pkg/commands/run.go

@@ -153,7 +153,9 @@ func initFlagSet(fs *pflag.FlagSet, cfg *config.Config) {
 		wh("Show only new issues: if there are unstaged changes or untracked files, only those changes "+
 			"are analyzed, else only changes in HEAD~ are analyzed.\nIt's a super-useful option for integration "+
 			"of golangci-lint into existing large codebase.\nIt's not practical to fix all existing issues at "+
-			"the moment of integration: much better don't allow issues in new code"))
+			"the moment of integration: much better to not allow issues in new code.\nFor CI setups, prefer "+
+			"--new-from-rev=HEAD~, as --new can skip linting the current patch if any scripts generate "+
+			"unstaged files before golangci-lint runs."))
 	fs.StringVar(&ic.DiffFromRevision, "new-from-rev", "",
 		wh("Show only new issues created after git revision `REV`"))
 	fs.StringVar(&ic.DiffPatchFilePath, "new-from-patch", "",