Junio C Hamano <gitster@xxxxxxxxx> writes: > On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote: >> >> Given this, enabling Travis CI for git/git seems pretty low risk, >> are there any strong objections to it happening? > > I still don't see a reason why git/git needs to be the one that is > used, The very nice thing with Travis-CI is that it does not only test the repository's branches, but also all pull-requests. So, if it is activated on git/git, it will become possible to have a flow like 1) User pushes to his own repo, sends a pull-request, 2) Travis-CI notices the pull-request and builds it (no action needed from anyone), 3) Once the build is finished, the user can use e.g. SubmitGit to actually submit the code. This has real benefits for the submitter (know if your code is broken early), for the reviewers (things like "you have a def-after-use" would be noticed by a computer before human beings start spending time on the review), and for you (some issues noticed before a topic enters pu). There's no extra work for the user at all compared to the standard pull-request flow (nothing to do, just submit a PR), and a one-time setup for the project. Currenty, to mimick this flow, we would need something like 1) User activates Travis-CI on his repo (each user would have to do this, not just once) 2) User commits .travis.yml on top of the code to submit 3) User pushes to his repo 4) Travis-CI triggers a build 5) User removes the commit introducing .travis.yml, force-pushes 6) User submit the resulting code. This is much more work for the user (read: nobody will do it, actually nobody do it currently) and less convenient for reviewers (who have no way to check whether the build passed). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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