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

From: Roberto Tyley <roberto.tyley@gmail.com>
Date: Feb 9, 2016, 23:03 UTC
Message-ID: <CAFY1edbCSPZg892=pVQ=TDo6PRhUdees36Jp7LQ2YB3_jQd4uQ@mail.gmail.com>
In-Reply-To: <xmqq4mdh4tel.fsf@gitster.mtv.corp.google.com>

On 9 February 2016 at 18:42, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> 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.