On 2015-12-02 00:32, Donald Stufft wrote:
>
>> On Dec 1, 2015, at 6:24 PM, Brett Cannon wrote:
>>
>> It's Dec 1, which means it's time for any questions people have about the
>> proposed workflows so we can get answers by Dec 15.
>>
>> I have one question that applies to both proposals and one s
> On Dec 13, 2015, at 7:55 AM, Christian Heimes wrote:
>
> On 2015-12-02 00:32, Donald Stufft wrote:
>>
>>> On Dec 1, 2015, at 6:24 PM, Brett Cannon wrote:
>>>
>>> It's Dec 1, which means it's time for any questions people have about the
>>> proposed workflows so we can get answers by Dec 15
On Dec 13, 2015, at 01:55 PM, Christian Heimes wrote:
>Merge commits are the single most idiotic feature in GitHub because GitHub
>enforces non fast-forward merges. Merge commits bloat and clutter the
>revision history with useless junk, e.g.
>http://ariya.ofilabs.com/2013/09/fast-forward-git-merg
Berker also said a bot could do the ff workflow which could also handle the
NEWS problem as well as long term branches. Assuming that's true and we
choose to solve those problems that way then it will be true on either
platform.
On Sun, 13 Dec 2015, 05:39 Donald Stufft wrote:
>
> > On Dec 13, 20
And couldn't we have a pre-merge web hook that always rejected merges
through the browser if we chose to?
On Sun, 13 Dec 2015, 14:31 Brett Cannon wrote:
> Berker also said a bot could do the ff workflow which could also handle
> the NEWS problem as well as long term branches. Assuming that's tru
For Github, Yes and No.
You can have status checks which will either prevent the merge, or will color
it yellow to indicate that it shouldn’t be merged (but will still allow it).
Unfortunately right now the implementation of preventing the merge unless all
status checks pass ALSO makes it so th
