When using `git log`, if some/all commits are gpg-signed, git will
automatically try to validate the signatures by default. This results
in printing additional text. This additional gpg-validation text is
then incorrectly interpreted by `git-validate` as if they were commit
IDs. Fix the problem by using the `rev-list` sub-command which will
ONLY list the IDs.
Signed-off-by: Chris Evich <cevich@redhat.com>
This is useful when you want to append additional elements to the env
var in the fasion of `PATH=$PATH:/things`.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Before this commit:
$ ./git-validation -run DCO -range HEAD^^..foo
2017/03/21 13:00:30 exit status 128
With this commit:
$ ./git-validation -run DCO -range HEAD^^..foo
ERRO[0000] [git] cmd: "git --no-pager log --no-merges --pretty=format:%H HEAD^^..foo"
2017/03/21 13:16:43 exit status 128
You can get similar output with -D, but folks are unlikely to set that
in production. With the new error logs, Travis output and similar is
more likely to contain some useful information.
Signed-off-by: W. Trevor King <wking@tremily.us>
Partially reverting ca825225 (git: do not include merges in the commit
range, 2017-03-21, #16). I've kept the unrelated --no-pager addition
from that commit.
I think merges in the commit range should be checked against whatever
criteria the caller is asking for. If the caller does not want to
check a machine-generated commit, they shouldn't include it in the
commit range.
And we already have special-cases for merges. For example, we skip
DCO checks for merge commits. I'd be happier without that special
case, because human-generated merge commits can still add novel code
(and therefore should have Signed-off-by), etc. But I don't think we
want a blanket pass for merge commits.
Signed-off-by: W. Trevor King <wking@tremily.us>
Swagat Bora
Vincent Batts