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