Re: [PATCH v1] travis-ci: override CFLAGS properly, add -Wdeclaration-after-statement

[Roberto Tyley <roberto.tyley@gmail.com>]

On 9 February 2016 at 18:42, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Schneider <larsxschneider@gmail.com> writes:
>> Jeff Merkey made me aware of http://kernelnewbies.org/FirstKernelPatch [2]
>> where I found checkpatch.pl [3]. Would it make sense to check all commits
>> that are not in next/master/maint with this script on Travis-CI?
>
> That does not help very much.  These changes are already shown to
> people and dirtied their eyes, and most likely I've already have
> wasted time tweaking the glitches out locally.  The damage has
> already been done.
>
> It would make a lot of sense if the checkpatch is called inside
> Roberto Tyley's "pull-request-to-patch-submission" thing, though.

I've not personally run checkpatch.pl (as Peff mentioned, it's not
actually a documented part of the Git project's recommend contribution
workflow) - I'm still trying to understand whether it will restrict
it's errors to just the things that are introduced in a patch, or if
it will indiscriminately mention existing problems too (of which I
guess there are many already present in the live Git codebase?). If it
mentions _existing_ problems, I wouldn't personally want it in any
automated flow until it can be tuned to find the trees of master/maint
totally clean. At that point it could be added to the Travis build,
and GitHub would automatically reflect the Travis status in any
git/git PR.

I like the idea of giving helpful guidance to users on how to make
their patches cleaner - I'm not that enthusiastic about submitGit
invoking the checkpatch.pl script directly at this point, given that
it lives in a separate project (the linux kernel) and the version
Junio uses is patched off _that_ - I'm lazy enough to not want to try
to get that all to work reliably on a little transient Heroku box.