From d3eb3ed74da9420eaaf79d242aa83d8330dbc4ca Mon Sep 17 00:00:00 2001
From: Romanos Skiadas <rski@arista.com>
Date: Tue, 7 Aug 2018 10:15:53 +0100
Subject: [PATCH] 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.
---
README.md | 5 +++--
README.tmpl.md | 2 +-
pkg/commands/run.go | 4 +++-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/README.md b/README.md
index 155a63c8..4578fa12 100644
--- a/README.md
+++ b/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)?**
diff --git a/README.tmpl.md b/README.tmpl.md
index 5783e92e..75526b0d 100644
--- a/README.tmpl.md
+++ b/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)?**
diff --git a/pkg/commands/run.go b/pkg/commands/run.go
index 5d6d4233..64421be0 100644
--- a/pkg/commands/run.go
+++ b/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", "",