| 1 |
On 05/06/16 18:09, rindeal wrote: |
| 2 |
> On 5 June 2016 at 18:53, M. J. Everitt <m.j.everitt@×××.org> wrote: |
| 3 |
>> On 05/06/16 17:49, rindeal wrote: |
| 4 |
>>> On 5 June 2016 at 18:40, Kent Fredric <kentfredric@×××××.com> wrote: |
| 5 |
>>>> On 6 June 2016 at 04:31, rindeal <dev.rindeal@×××××.com> wrote: |
| 6 |
>>>>> Isn't no commit approach better than having broken commit + revert |
| 7 |
>>>>> commit? |
| 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 |
> It is not, unless CI filters the broken commits in some miraculous |
| 20 |
> way. With the current approach, both stable and master branch will |
| 21 |
> contain the pollution of broken commits + their fixes, instead of |
| 22 |
> having good commits only. |
| 23 |
To eliminate errors completely, you also remove any form of progression. |
| 24 |
As the old proverb goes "you can't make an omelette without breaking |
| 25 |
eggs".... |
| 26 |
|
| 27 |
This way, at least the bad commits /get/ fixed *before* they are pushed |
| 28 |
out to unsuspecting users ... ok so its not perfect, but this _is_ the |
| 29 |
real world here ...... |
Archives