On 9 February 2016 at 18:42, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Lars Schneider <larsxschneider@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html