On 5 June 2016 at 18:53, M. J. Everitt <m.j.ever...@iee.org> wrote: > On 05/06/16 17:49, rindeal wrote: >> On 5 June 2016 at 18:40, Kent Fredric <kentfred...@gmail.com> wrote: >>> On 6 June 2016 at 04:31, rindeal <dev.rind...@gmail.com> wrote: >>>> Isn't no commit approach better than having broken commit + revert >>>> commit? >>> >>> Huh? >>> >>> Its doing "replicate to github on pass using a merge commit". >> I'd like to see the master branch free of commits which do not pass >> CI, instead of having broken commits and holding master back until >> revert commits are introduced. >> > Which is the whole idea .... 'stable' becomes fully CI parsed good > 'green light' whereas master is a 'holding bay' until the CI script can > do its stuff .. >
It is not, unless CI filters the broken commits in some miraculous way. With the current approach, both stable and master branch will contain the pollution of broken commits + their fixes, instead of having good commits only.
